AS3 — on the lack of private and protected constructors
As I was talking about using objects as enums, someone made a comment about the lack of private and protected constructors. I know that the this is a sore spot, so I thought I’d explain my view of how we got here, and give my two cents.
The problem is that unlike what we did with ActionScript 2, we are working tightly with people from Mozilla and others to standardize on ECMAScript edition 4. The ECMAScript standard is not final, but we are adhering as closely as we can to the spec as it develops.
~
Private and protected constructors is not something that the group has been able to tackle yet, and it is a nontrivial change to the language that requires lots of careful thought.
Ideally, we would have been able to think through all the ramifications of private and protected constructors and work with other ECMA members to make sure the design was sound, but that just wasn’t possible in the amount of time we had.
Given this, there were three choices:
1) Delay ActionScipt 3 (and Flex, etc.) significantly.
2) Just “go with” a quick and dirty implementation of private and protected constructors for AS3 and risk compatibility problems down the road once the ECMA spec becomes final.
3) Don’t allow private and protected constructors for now.
We went with option (3).
The main uses of private and protected constructors are singletons and abstract base classes. In both of these cases, I agree that the lack of real private and protected constructors is a pain. There are hackarounds which will work for now, but I am eagerly awaiting the day when we don’t have to use them anymore.
As for the specific use case described in the previous post (using objects as enumerations), the main thing that private/protected constructors allows you to do is to ensure that the set of “enum” values cannot be extended later by someone else.
I personally like having this level of control, but I am willing to live without it. It “feels better” to create a system where no one can add any more values to the enumeration, but in practice,
a) If people create new values for the enumeration and try to use them with code that wasn’t expecting those values, it will obviously break. So who is going to do this?
b) If people create new values for the enumeration and use them only within their own code… well… it kind of breaks the spirit of what an enumeration is, but it might be just fine.
Here’s a concrete example of scenario (b). Imagine that I create a text control with three values for alignment: LEFT, RIGHT, and CENTER. Someone subclasses this control, and wants to create a fourth enumeration value: JUSTIFY. This new value would obviously only be useful for this person’s subclass, but who am I to say that he/she shouldn’t create it?
Like I said, I would ideally like the option of controlling what can and can’t get extended, but in the case of enumerations, I’m ok with not having that control for now.
Glad to hear that protected and private constructors are just postponed. I really thought this was a limitation Adobe considered as a feature. At least I can now stop publicly whining about it. ;)
And yes, they are not that important for enums. I miss them more for abstract classes and always thought that, for example, DisplayObjects constructor throwing runtime exceptions is not an elegant solution since this should be detected at compile time.
Btw. since enum and abstract are reserved keywords, is there a chance we see those features in AS 4 or is this something the spec group is currently not working on? And are there any drafts of the spec publicly available? If I google for it, all I can find are drafts that are at least three years old.
And one more small thing I would like to see added to the spec in the future is a method like:
Class.newInstance(args:Array):Object
which would be kind of Function.apply for constructors. I know the workarounds using special initialization methods, but they might not be feasible for existing classes. In AS 2 it was easy to hack around this limitation using the __proto__ property. There were already several postings on Flexcoders for this issue, so I think I’m not the only developer missing this feature.
But I don’t want to come across too picky. ;-) AS 3 and especially the new Display API is a great step forward.
Enum and abstract are definitely things I could imagine being added to the language at some point. I don’t know if they are on the radar at present.
I’ll ask about whether the spec could be published in its current draft form.
As for Class.newInstance(args), that’s a good suggestion. Thanks!
Thanks for the clarification…I’m also glad to hear it’s only ‘postponed’ for the time being. I ranted about this way back when I first noticed it…
Maybe I missed this one, but what happened to ‘method overloading’ ?
You know, I don’t 100% remember what the discussion around method overloading. I recognize that it’s a useful feature, and we decided not to tackle it in ActionScript 3, presumably because of time.
I think the reason the lack of private constructors raised such a fuss is that unlike method overloading, this is a feature that was previously available in ActionScript 2.
I also wonder if you will also consider Destructor methods and/or operator overloading.
As far as I can see there’s no generalized method to clean-up when a application terminates. I have a javascript utility that dymanicaly creates media embeds into a DIV (or other HTML container). But on Opera the NetStream isn’t closed after the first dynamic embed on the page. So the flash video doesn’t play. Why are destructors missing? Is this the design of ECMAScript edition 4?
Thanks,
Enric
I am shocked. Do you mean that all constructors in fourth version will be locked? I dont understand you.
I am really glkad to glance at this web site pposts
which includes tons of valuable data, thanks for providing such data.
Feel free to visit my blog post … sleep diary
It’s impressie that you are getting thoughts from
this article as well as from our argument made here.