What happened to constructor parameters?
Having been working alot with components in AS3 lately, it just struck me that most of the components have no parameters in their constructors.
I can see that when using MXML there is no need for constructor parameters (since properties are attributes), but I can seriously see the use for this in Actionscript, since common properties fit in there without making the code look ugly.
The next block of code, for example, would easily fit on one line, making it compact, and still be readable:
Actionscript:
-
var myInstance:OtherClass = new OtherClass();
-
public function MyClass ():void {
-
myInstance.width = 300;
-
myInstance.height = 400;
-
}
So is there some kind of harm done by properties as constructor parameters that I am missing?
July 25th, 2007 | Quote
@Tink: Good point! I think that a good example of what you said about read-only properties is the Event contructor, where you can set the bubbles and cancelable properties that need to be read-only after that..
However I do not think that contructor-parameters make code less readable per se.
Take for instance the Point class, it only has one other property of its own, so when I’m reading “new Point(110, 351)” it’s pretty obvious that it’s being assigned a coordinate.
This is in my opinion much more preferable than writing 3 lines of code just to set a coordinate..
So if this is the case for normal AS3 code, why not for classes in the Flex framework? I mean, just because those classes will be used mostly through MXML (where contructors cannot be used), doesn’t mean I will never add an instance of it through Actionscript (.addChild() ), does it?
@Neil: Perhaps Adobe did decide not to use constructor-parameters for the sake of consistency, I don’t think it makes the point less valid though..
July 25th, 2007 | Quote
As Eric pointed out, a lot of properties can’t be set that early on. MXML components don’t have a constructor, and so maybe they don’t pass args in to AS3 classes for the sake of consistency (even when those properties *could* be set in the constructor)?
July 25th, 2007 | Quote
There is no harm in using constructor parameters but IMO it isn’t as readable.
i.e this following uses constructor parameters. It passing 2 parameters but it isn’t immediately possible to see what those parameters are for.
—————————————————
var myComponent:MyComponent = new MyComponent( 400, 300 );
—————————————————
compared to the following where you can clearly see the 2 setters are for width and height. If the object has a well written API this is readable at a glance.
—————————————————
var myComponent:MyComponent = new MyComponent();
myComponent.width = 400;
myComponent.height = 300;
—————————————————
It makes sense to use (or you don’t have much choice) constructor params when the object requires those properties to be set when they are created, such as a BitmapData that requires a width, height and transparency property. These properties are then read only.
March 28th, 2007 | Quote
Yeah, I guess that’s a good point you’re making there. Though I still think that some properties (such as width and height) might look good as constructor parameters, even if it would mean a few more lines inside of the component-classes themselves; it’s all about the degree to which something is easy in usage, right?
That aside, I don’t really think Adobe’s going to go through the hassle of changing component signiatures merely in order to make this slight improvement, do you?
March 28th, 2007 | Quote
I think one of the big reasons behind this is the event cycle. A lot of properties simply cannot be set in the constructor, and would have to wait until the creation complete event to be set. Thus, you would have to set it once in the constructor…basically pending it til a time you could set it again, on creation complete. That and the lack of access to a constructor in mxml.