CODEWITHSUNDEEP
actionscript-3oop
ForYourOwnGood
ForYourOwnGood

Reputation: 40392

Actionscript 3.0, why is it missing good OOP elements?

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.

Upvotes: 2

Views: 510

Answers (3)

back2dos
back2dos

Reputation: 15623

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

Upvotes: 0

Josh Tynjala
Josh Tynjala

Reputation: 5242

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.

Upvotes: 3

Javier
Javier

Reputation: 62603

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.

Upvotes: 6

Related Questions