[boyzdynasty]

Can anyone answer this post

http://www.actionscript.org/forums/showthread.php3?p=228680#post228680

[stealthelephant]

i looked at it, it just seems that design is wrong, i mean like the base constructors will always be called shouldnt they?

[aurelius]

In standard OOP design, yeah, super constructors should always be invoked automatically. However, there are times when you don't want the super constructor invoked (e.g. if the base constructor is a static class or something), and so it's nice to have the ability not to invoke the constructor. This is one reason why I like the AS 1.0 prototyping. You can determine how the inheritance works because you actually have access to the inheritance chain of references (the prototype chain). So I can set inheritance so the super constructor is invoked like this:

[splict]

So stealthelephant, are you refering to actionscript or php? and are you saying its good design to automatically call the parent/super/base constructor or good design not to?

I don't know a bunch about as1.0, but I would agree with aurelius that as2.0 is probably compiled down to his first example. In as2.0, the super constructor is always called before anything else is done as is the case with most oop languages, I believe, unless you explicitly call the parent constructor. You can explicitly call it if you want, for instance, to invoke it later in your subclass' constructor (instead of doing it first thing).

In php the parent constructor is not automatically called. My guess as to why its like this is that its because php was not originally designed to be an oop language. In php5 you still have to explicitly call the parent constructor - I would think that this descision was so that they could maximize backwards compatability.

[stealthelephant]

i was talking c++, everything i do draws back on that language eventually. if u do not call the constructor explicitly then default constructors are called but they do nothing at all with any of the class members, the object gets created (php does the same but we never see default constructors), which is more or lese what u are referring to above.

i was wondering in what situation would u not want to call the subclass contructor cos i cant think of any situation when they not called (back to the default constructor).

[splict]

Good question! I would be interested in seeing a real world example myself. Since I am fairly new to real oop I can not think of a situation, off hand, where you would not want to either (without it being a poorly designed class). Maybe aurelius or freddycodes could enlighten us?

c++, huh? Any thoughts about moving to c#/.net? Thats what I'm learning now and I'm really enjoying it. Should be pretty easy for someone coming from a c++ background.

[stealthelephant]

c sharp?
kinda interested but i dont trust ms one bit! the mono platform is interesting but then again, netscape won in the courts against MS but where are netscape now?
i favour open source and standards, so much so i am staying away from the .net platform

[splict]

An understandable position. And its pretty silly of me to forget all of those posts you've made in the past that proclaimed your position. Still, pointers and all that? I tried once and I think it was a bit over my head. Of course I was just reading a book on an airplane

[stealthelephant]

c++ is only scary if u make it, pointers all right but bad programmers make cryptic code not the language

[aurelius]

I've run into a few occassions when I didn't want to invoke the super constructor. One example is an abstract, static class. In such cases, there's no reason to ever invoke the super constructor. We don't, for example, invoke the Math constructor when we use the class, simply because there's no reason to do so. We use it's methods and that's pretty much all we do with it. No reason to take up memory allocations just to use a static method. The same thing happens in my Thoth engine. I have a static class that keeps a counter running for its z-index (depth) and id dictionaries (and it also stores styles from stylesheets). All other Thoth classes inherit from this abstract class so they have direct access to this static counter and dictionaries. I don't need to invoke the constructor each time since a child class uses this, just like we don't need to invoke the Math constructor to use its methods. So abstract and/or static classes are the first example that comes to mind.

But there's also times when, as you cats rightly pointed out, when the super class is just poorly designed. If you're forced to extend the class via inheritance and don't have access to the class (e.g., your project manager won't let you mess with Joe's classes in the next cublicle, or perhaps you can't edit the super class because it's proprietary), then you might not want to invoke the super class's constructor, especially if that constructor performs a bunch of processes particular to that class but not particular to your child class.

[aurelius]

Just for fun, what would you all do with the following scenario. Suppose a company hires us to take an old single-window/document word processor and turn it into a multi-window/document word processor. The original single-window app was built with a single main Application class, with all the functionality built into that one class (bad design, yes, but hey, it was the 1980s). The project manager wants us to build a Document class which will be instantiated for and handle each document-window. The Application class is proprietary, and the original coders have long since gone onto other things, so basically we can't touch the Application class.

Since most of the application functionality is built into the Application class, our Document class needs to inherit that functionality from the Application class. But there's a problem: the constructor for the Application class does a lot of work -- it allocates memory, sets up garbage pools, initializes the graphics engine to draw the main window, and so forth. If our Document class is inheriting from the Application class, then each time a new Document class is instantiated, the Application class constructor would be invoked. But that clearly won't do because we don't want all that memory allocation, garbage pooling, and graphics engine initalization happening with each new Document instance. We only need that happening when the application first starts up.

So we have a problem: our Document class needs to use the functionality from the Application class, but we don't want the Application constructor getting invoked each time (and thus performing all that application initialization each time). How would you handle this? How would you get the functionality from the Application class without invoking the constructor?

[splict]

makes sense aurelius, thanks. But with the subclass of Math you wouldn't be insantiating an instance of it either, so you wouldn't be creating a constructor at all right? The Joe's class situation crossed my mind as well, but I wonder how you would handle this in a more structured language that automatically invokes the parent constructor? Also, I would be quite nervous about extending a proprietary class but not including its constructor - wouldn't that create a big oppurtunity for breaking your subclass?

[aurelius]

Yeah, I bet it would cause opportunity to break. The super class is poorly designed in the first place, which as stealthelephant mentioned, is always the cause of so much headache! I reckon it's usually poorly designed classes that force us to think of weird situations like this, or perhaps its that poorly designed classes put us in situations where solutions are not pretty either. Design the classes right from the start and things work well. Can you imagine working on something like MS Word, working with code that has been developed for over 10 years? Crazy! I bet they've come up with some pretty bizarre solutions to older poorly designed code that would strike us as completely insane today. Man, I'd just start over from scratch if I were the MS Word project manager, I'd build it right from the ground up (which is what other word processors such as, e.g., OpenOffice or Mellel are doing), and if that weren't an option, I'd quit. No way I'd touch code like that.

[splict]

That is very true. Wow! It's holloween type scary just thinking about trying to sort through code like that. And, like you say, the current code is probably just as crazy as the old code because it has to be just to deal with the legacy stuff... Man, developing on top of 10 year old code.... Thats like trying to add internet and sms messaging to my first cell phone - no thank you, I'd rather just junk it. Of course, cell phones don't cost quite as much as developing a feature rich word processor.

[stealthelephant]

was on way into work this morning and i thought of a reason myself, if you are going to over ride any settings done by subclass constructor then dont call it as it wastes cpu time