views:

334

answers:

3

Anyone who has programmed with actionscript 3.0 has most certainly noticed its lack of support for private constructors and abstract classes. There are ways to work around these flaws, like throwing errors from methods which should be abstract, but these work arounds are annoying and not very elegant. (Throwing an error from a method that should be abstract is a run-time check, not compile-time, which can lead to a lot of frustration).

I know actionscript 3.0 follows the current ECMAscript standard and this is the reason for its lack of private constructors, but what about abstract classes, are they not in the ECMAscript standard eather?

I guess the more specific question is why does ECMAscript standard not support private constructors? Is it something that can be look forward to in the future?

I have been wondering this for quit sometime, any insight will be much appreciated.

+5  A: 

private constructors and abstract classes are not "good OOP elements". they're nice hacks originated in C++. in more dynamic languages they're usually not needed.

abstract classes in particular are totally unneeded, since you don't have to declare the interface in the ancestor to comply with an interface. in fact, you don't even have to inherit from a common ancestor to use some polymorphism.

i'm not saying that AS is better without something like that; rather that you should think in the language you're using, not trying to translate from whatever you're used to.

Javier
+1  A: 

Neither private constructors nor abstract classes were defined in the old ECMAScript 4 standard on which ActionScript 3 was based. If I remember correctly, the ECMAScript Working Group chose not to implement these more complicated OOP features because there was a certain focus on simplicity and backwards compatibility with older versions of ECMAScript. I interpreted what I heard from them as "we may add these features later, but let's take it slowly". The abstract keyword, for example, is a reserved word, so they have this stuff in mind.

It's worth noting that the working group has chosen to restart the next version of the language with a new focus. This effort is called "Harmony" because two rival sub-groups had very different opinions about where ECMAScript should go in the future. It's a bit of a compromise. Harmony is going to progress much more slowly than the old ES4, and even the class syntax that was already implemented in AS3 will be dropped from the standard initially. In other words, they're going to keep it looking a lot more like today's JavaScript for a while to focus on some other features that are important to the group that was going to branch. This will become ES3.1. Later, classes and some of the more Java-like OOP features will be reconsidered for a new ES4.

What about AS3, though? Basically, Adobe jumped the gun by using a standard that wasn't yet complete, and they got bit by politics. However, Adobe intends to stay involved with the ECMAScript Working Group, and they will likely consider adding features that the working group recommends. That said, AS3 may never be a complete (or fully compatible) implementation of a future ECMAScript. What does that mean? Well, since they're non-standard again, Adobe has the option to add features to ActionScript, even if those features aren't part of a standard. If you feel abstract classes or private constructors are important to you as a developer, request these features in the public Flash Player bug database, or vote for existing feature requests, if they're already present.

joshtynjala
A: 

I know, this question is really old, but I just stumbled accross and had to amend this:

Constructors are not OO. Objects should be instantiated by factories.
Abstract classes are not OO. Instead one should use interfaces (which AS3 has) and mixins (which AS3 doesn't have).

AS3 is a poor language, but for many more fundamental reasons than these two. AS3 basically is a structured representation of AVM2 bytecode. A 1:1 mapping is easily feasible. And I suppose, it's likely to stay like that, because Adobe appearently has more interest in driving forward platform features, their commercial authoring tools and the flex framework (including mxml).

greetz
back2dos

back2dos
factories, interfaces and mixins have nothing to do with OO. in fact, constructors and abstract classes are closer to OO than any of those three. it can be argued about the merits and sins of each; but it seems that you're calling 'OO' just what is currently in fashion for Java.
Javier
@Javier: I really don't see, where I said, I'd like anything about Java. I consider Java an extremely poor language for OOP, due to serious design flaws (most AS3 design flaws can be directly tracked to Java). 1. For constructors, please refer to this post: http://tinyurl.com/22uthq . 2. Abstract classes are the completely degenerate result of the fact, that a lot of people think, OOP is about classes. It isn't. It's about objects, as the name states. A mixin defines partial funtionality, an interface describes behaviour. Abstract classes are just a really weird and ambiguous mix of both.
back2dos