« AS3 technique -- using object instances as "enums" | Main | New Flex component - Sliding Drawer v 0.5 »
April 5, 2006
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.
Posted by sho at April 5, 2006 9:03 AM