There’s a common thread of posts that have been running on blogs in the Flash community since the first beta releast of ActionScript 3.0. These have to do with making AS3 do stuff that it just doesn’t do, notably, singletons with private constructors, and abstract classes. The problem is, these things just aren’t part of the AS3 / ECMAScript spec, and just aren’t supported. You can’t really do them in AS3. Sure, you can kind of do them, and this is usually accomplished by throwing runtime exceptions when a programmer does something you don’t want him to do.
To me, these kind of solutions are complete hacks and at best are a pale imitation of what the feature really is in a language that supports it. It also seems like a whole lot of work just to make something fit in some predefined category that exists in other languages. An abstract class or singleton with a private constructor just wouldn’t compile if you used them incorrectly. Throwing a runtime exception is worlds apart from that.
Document your singleton as a singleton. If someone tries to create an instance of it anyway, tell them to RTFM. If they don’t, they’ll probably wind up with a runtime exception or some other error anyway. OK, I suppose it’s pretty considerate to at least give them an error that specifically tells them how they screwed up. So if you want to be that nice about it, cool. I’m not saying you shouldn’t throw an exception like that. I’m just saying that the vast amount of discussion on the subject on how to lock singletons down just doesn’t seem warranted. I’m also not saying private constructors aren’t useful, and wouldn’t be a great addition to AS3, but they aren’t there. So until they are, live with it, and don’t jump through hoops to try to fake them.
As for abstract classes, again, not supported, never have been, and I’m not sure whether or not they ever will be in ActionScript. Trying to create them anyway using runtime exceptions just seems ridiculous to me. When I see people trying to do stuff like that, I feel like they are stuck in some other language that has that feature and can’t seem to figure out how to do without it. If you are going to use ActionScritp, then learn ActionScript and program in ActionScript. When you program in, say, Python, you have a different mindset, different tools and features than you do when you program in, say, C++. And vice versa. I suppose you could write some kind of precompiler that would let you code C++ using indents for code blocks instead of curly braces so it felt more like Python. But it would probably be better to just learn C++ and use braces.
I’m probably coming off a bit blunt here, and don’t mean to insult anyone in who has worked on coming up with solutions like this. I just feel the effort is misguided and could better go into other aspects of application architecture. Often when you start creating complex solutions to things that should be simple, it is a sign you are going down the wrong path and could benefit from rethinking your basic assumptions.
I agree 100%. I have asked my self why would I rather fight the current to manipulate things the way I want them vs. going with my options and be prosperous with in my options.
I disagree, maybe not 100% though. Singletons and abstract classes are useful and, i feel, almost necessary in object oriented design. Granted runtime exceptions are poor substitutes for compile-time errors, and maybe these solutions should be avoided when the general public will be playing with your code, but for my own projects I find them very useful.
On the flip-side Brandon Hall worked hard on FLEM… and then it become the de-factor way to create events in Flash Player 6.
Bokel got sick of loadMovie _width questions, so wrote MovieClipLoader… which was then made THE class to use when loading things in Flash Player 7 & 8.
EventDispatcher was at the core of later Flash, and early Flex 1/1.5 apps, and incidentally the main bottleneck of the event based programming model. In ActionScript 3, it became built-in.
There are a lot of other minor examples, like 9 MovieClips turning into scale9, etc. The point is, while I agree that things like worrying about how to handle sessions is a learning curve people coming to ActionScript need to get over (we’re a stateful client people), programming methodologies and other conventions from other languages aren’t bad.
If enough people bitch about them, and bend over backwards to reach a comfort zone they had in another language… maybe it’s valid enough Adobe should implement it. History has shown this to be the common scenario. Besides, built-in Singletons and Abstract classes seem like a cool idea to me.
I think you’re just bloody content with ActionScript 3 and can’t imagine what all these traditional programmers are whining about when we already have the greatest platform on the planet to develop in. However, they don’t have the history of context for appreciation that you do, Keith, hehe!
…I just wish that threads got the same amount of attention… *ahem*…
I had the same thoughts when I was reading a couple of blogs recently. They were covering topics on how to implement Singleton and Abstract classes, using all kinds of approach to enforce the ideology.
Personally, I feel it is important to understand the classes before using them. If they are meant to be Singleton, document it and whoever using it should read about it. Using all kinds of approach and ‘hacks’ to get it through doesn’t seem to be a viable solution.
If Adobe and whoever working on the ECMAScript specifications pay attention to the development scene (which I hope they do), I am sure they will take things into considerations.
Tim, I agree abstract classes are useful in languages where they exist. However, they don’t exist in AS3. All I’m saying is that a pseudo-abstract class strung together with runtime exceptions is not all that useful. As for Singletons being necessary for Object Oriented Design, there are many who would say that Singletons are the antithesis of object oriented design. While I’m not totally in the “Singletons are Evil” camp, I do feel they are massively overused in many cases.
Jesse, again, I am all for having private constructors and abstract classes in AS3. Give me a petition to sign and I’ll sign it. As for history of context for appreciation, yeah, you got me there. I remember a coworker (a Java guy) bitching about the lack of refactoring tools available for AS in Flex Builder. I was like, man, you don’t understand, we are totally psyched that we have “rename” finally! Anyway, higher level things like events and scale9 seem a bit different than core language features like private constructors and abstract classes. The work on stuff like Spring and IoC for AS is very cool, for example. I think we just need to continue to let Adobe know what we need in terms of language features. Oh, I mean the ECMAScript board. Oh, pretty much the same thing… 😉
I’d throwing these errors is definitely worth the small amount of time it takes to implement them. Yes comments are useful, but the dev actually has to open the class, at least runtime error tells them of the problem and where it occurred.
Obviously ideally we’d have private constructors and proper an abstract keyword, but we don’t. This doesn’t mean we should sack singletons and abstract classes off all together, and if you are going to implement them, better implemented with runtime exceptions than no errors at all.
“All I’m saying is that a pseudo-abstract class strung together with runtime exceptions is not all that useful.”
Pseudo-abstract classes (or singletons for that matter) strung together without runtime exceptions are even less useful, because you could end up using the class incorrectly.
If I may paraphrase Dan Akroyd, “Keith, you ignorant slut.”
I think it is totally unrealistic to expect people to read the ASDoc for every class they use. Having an explicit runtime error is far better than some bizarre that shows up much later.
Also, Singletons and Abstract Classes aren’t just “features” of other languages – they are some of the core patterns used in object-oriented programming. The fact that they don’t exist in AS3 isn’t just a “different mind-set. Different mind-sets are for different programming paradigms like scripting languages with no type-safety – AS3 is still OO. These features are missing from AS3 because it isn’t fully mature. I will bet you $20 that within 5 years they will both exist in AS4.
Ignorant slut? I’ll assume that’s said with a smile. 🙂
Anyway Adam, you kind of prove my point. As a programmer who has just recently started using AS, you can’t see how you can do without abstract classes. Whereas someone who has come up using ActionScript doesn’t see what the big deal is. Sure, I have programmed in different languages, and know what abstract classes are and see the benefits, but I don’t stay up nights trying to figure out how they can be created in ActionScript.
As for private constructors, that was a colossal screw up. We had them in AS2. Ridiculous that they got dropped in AS3. I predict they will be back long before 5 years. I think you are probably right that abstract classes will eventually be part of AS3 too, especially since “abstract” is a key word reserved for future use. 🙂
How about an example? Take the flexunit classes. TestCase is the base class for all test cases. But you would never say new TestCase(). You extend it. If AS3 supported abstract classes, no doubt TestCase would be a prime candidate. It provides a common interface for test cases and some base functionality but is never intended to be instantiated itself. Would flexunit be better if TestCase threw an exception if it was instantiated directly? In this case I’d say definitely not, because it would probably look like a failed test, which would only confuse whoever tried to instantiate it more than they already were.
Well, just because abstract isn’t supported in AS3, it doesn’t mean you aren’t using it. Anything with inheritance will inevitably have cases where there is a base class that is just meant for common functionality (and anything with classes will eventually have a case where you only want one created). So you have this pattern in AS3 just like Java, Python or C#, just you have no way to describe or enforce it. So I think throwing exceptions etc is a fairly natural and reasonable response. I don’t think ‘programming without thinking that way’ is natural AS3 – or do you think base classes should always be instanciable?
That being said I see your point too. For example we also often have a need to not *internally* modify the state of a variable, other than through an accessor. There is no support for enforcing this in any language that I know of. We can declare private, but that still is open to internal change. I guess the idea is we trust ourselves, but not others — however personally I don’t like trusting myself either : ). In fact that vast majority of all Flash code is only ever used by the person who coded it, so ‘abstract’ and ‘singleton’ patterns are there because we (rightly) don’t want to have to trust ourselves, we want to be told when we screw up. So, are there legions of people running around trying to screw up the readability of their code, adding private internal classes (or worse etc) that prevent us from internally assigning to a variable? No. Why not? Because that is considered acceptable in other languages. There are thousands of examples of useful things not supported in other languages that no one worries about. So in that sense, all of this does seem like language envy and excessive hand wringing.
For the record though, I agree that it is really stupid to not have these in an oo language, given they are so trivial to implement, and optional to use. The JS world has a big identity crisis, and it is resulting in a pretty ugly frankenlanguage. It is the extra effort of a Java, but the extra benefits of AS1.
Cheers,
Robin
PS Rename doesn’t always work right in Flex, mostly because of the language design I’m sure – I guess that goes a long way to explaining why there isn’t more of the good stuff from the refactoring side : ).
Robin, I think I agree with you 100%, and probably didn’t state myself clearly enough in my rush to get out a rant. 🙂 Of course I use classes that aren’t meant to be instantiated, only extended. I just gave an example with TestCase. It’s exactly that stuff like private internal classes and other overly complex overengineering like that designed for what? to prevent someone from creating an instance of a singleton? As you so succinctly put it, “language envy and excessive hand wringing”. And again, I agree that the majority of code gets used by the person who writes it only, or maybe 1-2 other people. I can see the point of using an exception in a base class that’s going to go out to the world at large. But I trust myself to not create instances of my own singletons. 🙂 And even in one of the largest 3rd party code bases for AS, flexunit, I don’t see a massive uproar by people instantiating TestCase.
Actually, there are classes that behave as abstract in flash the package that throw runtime exceptions if instantiated directly. Prime example, the DisplayObjectContainer class. See:
http://livedocs.adobe.com/flex/2/langref/flash/display/DisplayObjectContainer.html
It is essential that the DisplayObjectContainer behave as a true abstract class as it implements the composite pattern. Instantiating a DisplayObjectContainer class and NOT implementing the abstract methods (I should say the methods that should behave as abstract) would break the display list. Not throwing a runtime error would be critical in this case.
Although I’d love “abstract”, after reading:
http://www.bigroom.co.uk/blog/better-without-singletons
I would query whether Singletons are a “core” pattern at all.
As far as abstract is concerned I just call my abstract classes things like “AbstractDooDah” or “AbstractWidget”. The name is a pretty good clue.
“Would flexunit be better if TestCase threw an exception if it was instantiated directly? In this case I’d say definitely not, because it would probably look like a failed test, which would only confuse whoever tried to instantiate it more than they already were.”
Yes is should throw and exception stating that the class is abstract so the dev knows the exact problem. Yes the test would fail, but it would fail with a meaningful error, not confusing the dev, but shedding light on the problem.
I’ve never heard of anyone having a problem with flexunit because they were instantiating TestCase. This is adding extra code to solve a problem that doesn’t exist.
Anyway, I think I’m arguing just for the sake of arguing now. 🙂 I appreciate all the comments so far. But unless someone calls me a slut again, I’ll just let the conversation continue on its own.
Hi, kp
There is a great article that explains the reason why AS3 doesn’t have private and protected constructor support as well as abstract classes. Here it is:
http://kuwamoto.org/2006/04/05/as3-on-the-lack-of-private-and-protected-constructors/
Thanks for sharing your thoughts, Keith. I’m one of the folks who implemented a pseudo-abstract class in AS3. I don’t think I’ve never actually used my method in a real project, but it was a fun academic exercise where I feel like I learned something new based on experimentation.
I agree with you, though… mostly. One thing I’d like to add is this: If people don’t build hacks like these for the features they want, the desire for those features won’t be as obvious to the powers-that-be. Because there has been so much public discussion about singletons and abstract classes, I suspect that Adobe and the ECMAScript committee will be more likely to consider the required features in future versions.
Yeah, in retrospect, I probably came off too harsh on this one. I didn’t really mean to say that by no means should you do this kind of stuff, just that you should evaluate the real necessity of it before going through all the extra work. If you are the only one using your singleton, do you really need a private inner class with exceptions to make sure you use it correctly? Personally, I don’t. But in larger scale, multi-team projects or publicly released code bases, maybe it is warranted.
I feel you keith, throwing run-time errors to enforce abstract methods makes me feel dirty just thinking about.
But what other choices do i have.
Since MXML classes cannot implement interfaces what other choice do i have than to create a pseudo abstract class.
Singletons is another one.
I guess i’m just jumping on the bandwagon with the other guys posts.
Actually, Bjorn, MXML classes can implement interfaces. See About interfaces in the LiveDocs for more information.
Man now I feel like a real d*ck..
Can’t believe I didn’t know that.. Thanks..
Ahh, but isn’t one of the great beauties of the Flash community that is creates useless experimentive crap? You’ve created a lot of useless crap on your website that I happen to think is very cool and watch your blog because it causes me to think about new things or old things in new ways. I may never use it and you may never use it, but we can both become better developers because of it. I come from a C++ background and am one of the sad ones that misses private constructors, abstract classes, and especially, function overloading (in AS3). I love seeing the creative “hacks” that people have come up with to implement some of these things. I don’t personally use any of these hacks and I bet there is an extremely small population of people that actually do. But all in all, I believe it is healthy for the community for two main reasons:
1) it stimulates thinking outside of the box
2) it helps the powers that be to know how badly we want it
So, although I would agree with you that I wouldn’t use any of these hacks, I’m surprised that you would come off in a tone that attempts to stifle people who attempt to make them. Just my $0.02
Nate, I came to a similar realization myself the other day. 🙂 I was probably just in a crabby mood that day.
You have to look at why this is the case. Actionscript for the most part is a client side language. I absolutely love AS3 but the bloat like abstract classes, getters setters etc were left out mainly due to bloat and size. I think that in most cases you can get by without abstract classes using interfaces and inheritance but yes it is a missing feature. For Singletons the whole idea of them is to great a global copy which AS3 can do static but again client side so it was limited in scope. I think AS3 is perfect, from here on out it starts to bloat. As a client side technology (like javascript) they need to think that one through before it gets to strict. Especially with the functionality dynamic movements going on and being client side mostly it NEEDS to be about compact minimalist code. Macromedia was very good about this, I hope Adobe is as well. It is what makes the AMF and AMF3 formats so great, FLV, etc. I have to say AS3 is the most fun version of actionscript yet from a flash 3’er, it is very powerful being based off of ES4. The event model, bytearray support, sockets are so key. I don’t have many complaints. I will if it bloats.
hAxe will keep the bloat in check maybe? 🙂 btw I meant functional/dynamic movement (Ruby, Python, etc) not the functionality movement. If as bloats head to haXe.
Given that Jeff Dyer is mentioned in this bug and it’s Resolved for ECMAScript 4, I’d bet that private constructors are coming:
http://bugs.ecmascript.org/ticket/166
An OO language without abstract classes is barely an OO language at all. The proper way to think when developing an app OO style is to develop 70% of it in abstract classes, and the rest as instantiable classes. In other words, abstract classes aren’t an afterthought, they’re the thought. Hacking AS 3 into a proper language is all we’ve got.
OK Bog, so go code in a proper OO language. We can all complain about ActionScript and try to make it something it isn’t, or we can get on with life and create stuff with it. Yeah, it’s good to bring these things up so the language evolves into what the community needs and wants, but the “it’s not a REAL OOP language until it supports X” attitude gets on my nerves sometimes.
I have of anyone having a problem with flexunit because they were instantiating TestCase. This is adding extra code to solve a problem that doesn’t exist.
dizi izle
Dizi, I agree.
It’s been mentioned that Adobe uses implementations similar to these with some of their classes, DisplayObjectContainer being the example given for a class that acts like an abstract. One that comes to mind for the singleton pattern is Camera, which must be accessed using getCamera() to function properly. While they allow you to create an instance with a constructor, you can’t actually use it to get to the camera hardware.
I guess my question is, why would Adobe leave out some OO features like these if they’re going to create classes that mimic them anyways? Probably not the last time I’ll be puzzled by their implementation choices, unfortunately.
Trying to create Abstract classes using runtime exceptions just seems ridiculous to me, too. Interfaces are good enough. On the other hand, “private” contructors should have been supported in as3 because singleton patterns is useful.
100% agree.
Runtime exception stinks, everyone should be teached that early.
Why? Because first, you need to compile and run your application. Then you have to interact with your app, up to the point where the exception is thrown… this is time consuming in the case you know there is a bug, and the steps to reproduce it. And when you don’t know there is a bug, it’s a lot worse.
I apologize for not remembering who said it first…
Singleton w/o RTE’s
http://pastebin.com/AmHqPF4G
Totally agree with this article.