I can't believe how long I went without using superclasses with their polymorphism. I mean, I used base classes when I created linkage for my movie clips, but I never made a class to extend to before. This is going to make everything so much easier!

I feel like I'm actually learning.

For other amateurs who aren't using these things: get into them now. Stop putting everything into your document class (or the timeline) and start using classes.

I wonder if I'll ever need to bother with interfaces. I don't really understand them, yet.

At 1/23/15 06:43 PM, Barzona wrote: I wonder if I'll ever need to bother with interfaces.

The neatoness of things grows exponentially in the direction of interfaces and beyond.

Dunno if I can spam this link enough.

At 1/23/15 06:43 PM, Barzona wrote: I can't believe how long I went without using superclasses with their polymorphism. I mean, I used base classes when I created linkage for my movie clips, but I never made a class to extend to before. This is going to make everything so much easier!

I know I'm way behind all of you guys in terms of skill... I've been teaching myself for a year now (give or take a few weeks) and I just figured out how to extend classes. For example making an enemy class that stores things like hp and behavior and then having my different types of monsters extend that enemy class. Using override functions is neat too.

I feel like I'm actually learning.

Love that feeling :)

I wonder if I'll ever need to bother with interfaces. I don't really understand them, yet.

Never heard of interfaces before....I will have to look into them....

One thing I don't really understand is the use of the word "super". Can anyone explain it better to me than what I've read online?

Would it work like this with my example of enemy and monster classes that I just talked about:

// inside public class Enemy extends MovieClip

function someFunction():void
{
    // do stuff
}

// inside public class Monster extends Enemy

super.someFunction();  //calls the someFunction in the enemy class

Is that how you use the super keyword? If so, is it just so you don't have to declare the Enemy class inside of the Monster class to access it?

helpful hint whenever you extend a native class for specific purpose, extend it with a general base class. Leave it empty for the time being. Then extend that with the specific purpose class. If any new class requires functionality from that class, move it to the base class.

Whenever I start a project for a new language/engine, I always extends the native sprite equivalent class and add
setDefaults
init
update
destroy

They're usually empty. Usually any logic in there is enabled/disabled using booleans. So my hero class might just have a few lines in the set defaults

usePhysics = true;
maxSpeed = 10;

Stuff like that.

At 1/23/15 08:52 PM, Hero101 wrote: One thing I don't really understand is the use of the word "super". Can anyone explain it better to me than what I've read online?

class BaseTest {
	public function blah():void {
		trace("Hello, world!");
	}
}

class Test extends BaseTest {
	override public function blah():void {
		//stuff
		super.blah(); //traces "Hello, world!"
		//more stuff
	}
}

Protected functions are also helpful when using overrides.

At 1/23/15 09:08 PM, egg82 wrote:

At 1/23/15 08:52 PM, Hero101 wrote:

Oh so I was correct with ways to use super then? It's just a way to access the parent class?

Protected functions are also helpful when using overrides.

I have never looked into protected functions. I was told to first get a grasp of using public and private functions first. Like I said it's been a year now of programming and I understand when/how to use public and private variables/functions. What's the different between private and protected? What's the benefit of using protected? I've looked at a lot of advanced classes written by programmers years ahead of me and they often had a ton of protected functions so I know it must be really useful...

At 1/23/15 09:26 PM, Hero101 wrote: Oh so I was correct with ways to use super then? It's just a way to access the parent class?

Pretty much, yeah.

What's the different between private and protected?

private is something only that class can see.
protected is something that class and any class that extends that class can see.

class BaseTest {
	private function doStuff():void {
		//do stuff
	}
	protected function blah():void {
		//do more stuff
	}
}

class Test extends BaseTest {
	override private function doStuff():void { //compiler error
		
	}
	override protected function blah():void { //works just fine
		
	}
}

What's the benefit of using protected?

It can come in handy. If you want something you can override or access when you extend the class, but don't want to expose it, then you use protected.

At 1/23/15 09:26 PM, Hero101 wrote: What's the benefit of using protected? I've looked at a lot of advanced classes written by programmers years ahead of me and they often had a ton of protected functions so I know it must be really useful...

Haxe doesn't have private like as3 does. Haxe's private == as3's protected. It does have getters and setters with various levels of access.

Most things can be left protected or public. Private is like "if you touch this you die" in my eyes.

At 1/23/15 10:37 PM, MSGhero wrote: Haxe doesn't have private like as3 does. Haxe's private == as3's protected. It does have getters and setters with various levels of access.

Never liked that, to me private was always, "no need to clog up your auto complete with all these"

Most things can be left protected or public. Private is like "if you touch this you die" in my eyes.

also, this.

At 1/24/15 12:07 AM, GeoKureli wrote:

At 1/23/15 10:37 PM, MSGhero wrote: Haxe doesn't have private like as3 does. Haxe's private == as3's protected. It does have getters and setters with various levels of access.

Never liked that, to me private was always, "no need to clog up your auto complete with all these"

You can turn off autocompletion with a @:noCompletion tag, but that kinda defeats the purpose of not having as3-private...

It does make the difference between protected/private easier to understand though.

At 1/23/15 09:37 PM, egg82 wrote:

At 1/23/15 09:26 PM, Hero101 wrote:

private is something only that class can see.
protected is something that class and any class that extends that class can see.
It can come in handy. If you want something you can override or access when you extend the class, but don't want to expose it, then you use protected.

Oh I get it now. Thank you this really clears up a lot of confusion for me and I understand it now.

At 1/24/15 12:48 AM, MSGhero wrote:

At 1/24/15 12:07 AM, GeoKureli wrote:

At 1/23/15 10:37 PM, MSGhero wrote:

Most things can be left protected or public. Private is like "if you touch this you die" in my eyes.

haha

It does make the difference between protected/private easier to understand though.

It does. I will have to start using protected over private more often. So from what I gather between you and @GeoKureli is that I could essentially just do away with private from here on out and just use protected instead given I'm using AS3?

At 1/24/15 01:29 AM, Hero101 wrote: It does. I will have to start using protected over private more often. So from what I gather between you and @GeoKureli is that I could essentially just do away with private from here on out and just use protected instead given I'm using AS3?

I usually typed private because it shows up first in autocomplete when you type "pr." If I ever extended that class, I always had to go back and Replace All to change the privates to protecteds since that's 98% of the time what I wanted.

At 1/24/15 01:29 AM, Hero101 wrote: It does. I will have to start using protected over private more often. So from what I gather between you and @GeoKureli is that I could essentially just do away with private from here on out and just use protected instead given I'm using AS3?

start out with private, change it if it needs to be protected

At 1/24/15 01:52 AM, GeoKureli wrote:

At 1/24/15 01:29 AM, Hero101 wrote: It does. I will have to start using protected over private more often. So from what I gather between you and @GeoKureli is that I could essentially just do away with private from here on out and just use protected instead given I'm using AS3?

start out with private, change it if it needs to be protected

Is there an issue with using protected even if I don't plan to extend the class?

At 1/24/15 05:01 AM, Hero101 wrote: Is there an issue with using protected even if I don't plan to extend the class?

No, but as a general rule:

K - Keep
I - It
S - Simple
S - Stupid

don't make things complicated for the sake of making it complicated.

At 1/24/15 05:15 AM, egg82 wrote:

At 1/24/15 05:01 AM, Hero101 wrote:

No, but as a general rule:

K - Keep
I - It
S - Simple
S - Stupid

haha :P

don't make things complicated for the sake of making it complicated.

How would using protected over private make things complicated...? As @MSGhero said, "If I ever extended that class, I always had to go back and Replace All to change the privates to protecteds since that's 98% of the time what I wanted." Just seems like declaring them as private ultimately causes more "complication" in projects. Again, I'm new to the use of using protected functions so I'm just asking to better help myself understand it all.

At 1/24/15 06:17 AM, Hero101 wrote: All to change the privates to protecteds since that's 98% of the time what I wanted.

That's what works for him, and he's more experienced than you are. Private is simpler to use and understand than protected, and on top of that if you share your code and there's protected functions everywhere nobody (including yourself) will know that you're just using those and not, in fact, planning to extend that class. and override those. There's a time and place for everything.

On top of that, you really don't want to expose your methods all that often. What would happen if motherboard manufacturers all of a sudden decided one day they were just gonna leave all their wires and bits hanging out everywhere because you never know when someone might want to come along and extend that functionality?

At 1/24/15 06:17 AM, Hero101 wrote:

How would using protected over private make things complicated...? As @MSGhero said, "If I ever extended that class, I always had to go back and Replace All to change the privates to protecteds since that's 98% of the time what I wanted." Just seems like declaring them as private ultimately causes more "complication" in projects. Again, I'm new to the use of using protected functions so I'm just asking to better help myself understand it all.

there's definite times when you know something won't be overriden, and there's also private properties with getters /setters. it's not a big deal to always say protected, and it's not a big deal to go back and change privates to protecteds. try something out and see what feels right

At 1/24/15 01:02 PM, egg82 wrote:

At 1/24/15 06:17 AM, Hero101 wrote:

That's what works for him, and he's more experienced than you are. Private is simpler to use and understand than protected, and on top of that if you share your code and there's protected functions everywhere nobody (including yourself) will know that you're just using those and not, in fact, planning to extend that class. and override those. There's a time and place for everything. On top of that, you really don't want to expose your methods all that often.

Thank you for the clarity and feedback. All of this really helps clear things up for me. I really do appreciate it.

At 1/24/15 01:05 PM, GeoKureli wrote:

At 1/24/15 06:17 AM, Hero101 wrote:

there's definite times when you know something won't be overriden, and there's also private properties with getters /setters. it's not a big deal to always say protected, and it's not a big deal to go back and change privates to protecteds. try something out and see what feels right

Ah yes getter/setters. I still don't understand how those work. I will have to go back and review them again (it's been a few months) and see if I can better grasp them now. Thanks for your input dude.

At 1/23/15 06:43 PM, Barzona wrote: I can't believe how long I went without using superclasses with their polymorphism. I mean, I used base classes when I created linkage for my movie clips, but I never made a class to extend to before. This is going to make everything so much easier!

I feel like I'm actually learning.

For other amateurs who aren't using these things: get into them now. Stop putting everything into your document class (or the timeline) and start using classes.

I wonder if I'll ever need to bother with interfaces. I don't really understand them, yet.

In QuakeC we have none of these things. And everything works fine.
All you're getting is more abstraction and thus slowness when you don't realize it.
We don't even have fast arrays in quakeC, got to use a bunch of variable... but that's what an array really is anyway so no loss.

Keeps you on your toes and all.

Guess I'll toss a link: http://www.moddb.com/games/chaosesqueanthology

All you're modern things...

In QuakeC we have none of these things. And everything works fine.
All you're getting is more abstraction and thus slowness when you don't realize it.
We don't even have fast arrays in quakeC, got to use a bunch of variable... but that's what an array really is anyway so no loss.

Keeps you on your toes and all.

Guess I'll toss a link: http://www.moddb.com/games/chaosesqueanthology

All you're modern things...

Can't tell if he's trolling...

At 2/7/15 07:11 AM, MikeeUSA wrote: In QuakeC we have none of these things. And everything works fine.

Dunno why you're arbitrarily limiting yourself by writing in c-like bytecode designed for modding Quake, but alright.

All you're getting is more abstraction and thus slowness when you don't realize it.

Might as well write it in assembly, then.

We don't even have fast arrays in quakeC, got to use a bunch of variable... but that's what an array really is anyway so no loss.

Oh, fuck everything to do with that. I'd make my own array class at that point.

Keeps you on your toes and all.

*Prevents you from furthering your education in game development by writing in old, archaic languages that have little to no support for anything remotely useful

All you're modern things...

I don't know if 1994 (or 1983) is modern by comparison to game technology, but alright.

At 2/8/15 03:50 PM, egg82 wrote:

At 2/7/15 07:11 AM, MikeeUSA wrote: In QuakeC we have none of these things. And everything works fine.

Dunno why you're arbitrarily limiting yourself by writing in c-like bytecode designed for modding Quake, but alright.

All you're getting is more abstraction and thus slowness when you don't realize it.

Might as well write it in assembly, then.

We don't even have fast arrays in quakeC, got to use a bunch of variable... but that's what an array really is anyway so no loss.

Oh, fuck everything to do with that. I'd make my own array class at that point.

Keeps you on your toes and all.

*Prevents you from furthering your education in game development by writing in old, archaic languages that have little to no support for anything remotely useful

All you're modern things...

I don't know if 1994 (or 1983) is modern by comparison to game technology, but alright.

You know why Russian weapons are good.
They keep it simple.

Assembly isn't multi-architecture compatable though.
I don't know why DarkPlaces arrays are so slow, maybe you could fix them. (If you do please tell me so I can backport)

At 2/7/15 11:59 PM, GeoKureli wrote: Can't tell if he's trolling...

Not having the conveniences makes you do without or make an abstraction, and in that you actually realise the performance penalties in what others take for granted and don't think about.

One's "Simple structure" actually is 100 lines of code (or even more!), and you want to run that every frame?
It makes you rethink things and implement them more efficently.

That's why this is not so bad.

Speaking of keeping it simple, pre-optimization is bad.
C/C++ standard libraries are as solid as you'll ever get. Why re-invent the wheel?

At 2/8/15 04:03 PM, egg82 wrote: Speaking of keeping it simple, pre-optimization is bad.

I've always wondered why that is. Surely there are things we can be doing as we go along to ensure good performance by the end.