We have always had access to .prototype but trait methods could not be overwritten. This reverses that in a compiler flag.”

I don’t really want to rain on your excitement, but I believe that the only reason that you are able to override (in effect) those particular methods is because the ‘core’ classes (the top-level ones) were mandated by the ES4 draft spec to be defined on the prototype. They’re also defined the ‘regular’ way so that they still end up in the traits object for each class.

However, if you look carefully at the declarations of the methods of those classes in the AS3 docs, you’ll notice that the methods are not public; they’re defined in the ‘AS3′ namespace. That trickery allows them to be bound as regular methods unless you use the compiler flags that you were talking about. Since the AS3 namespace isn’t open by default anymore, your property access attempts will actually be able to reach the prototype versions.

Sadly, the rest of the built-in classes use methods that are in the public namespace (and they don’t even have prototype versions), so you won’t be able to get around the bound versions using your compiler flags. The most notable impact of this is that you can’t redefine the methods of practically any of the other built-in classes, like Sprite.

Found the most awesome ASC compiler flag of all time. -es -as3=false. It allows fully editable prototyping using AS3.

-es -as3=false makes this street legal: Array.prototype.push = function():void{ trace(‘push’) } override trait based methods.

By default you cannot overwrite Trait based class methods. Using “-es -as3=false” runs everything via prototype but with JIT.

We have always had access to .prototype but trait methods could not be overwritten. This reverses that in a compiler flag.

It is really great for those doing work in AS3 in Flash Pro and ASProject. It is super handy rewiring player methods http://proto.layer51.com/

And if you want to get really dynamic try “-es -as3=false -strict=false” suddenly your back in as1 land with JIT.

Take a look at this example, I reassign the Array.prototype.push method 2 times with execution:

01.package {
02. import flash.display.Sprite;
03.
04. public class ESFla extends Sprite
05. {
06. public function ESFla()
07. {
08. Array.prototype.push = function( value:Object ):void{
09. trace(’1st definition of push:’ + value);
10. }
11. var a:Array = [];
12. a.push(‘foo’);
13. Array.prototype.push = function( value:Object ):void{
14. trace(’2nd definition of push:’ + value);
15. }
16. a.push(‘foo’);
17. }
18. }
19.}

Crazier still, create ‘push’ on Object and delete Array.push at runtime:

01.package {
02. import flash.display.Sprite;
03.
04. public class ESFla extends Sprite
05. {
06. public function ESFla()
07. {
08. Array.prototype.push = function( value:Object ):void{
09. trace(’1st definition of push:’ + value);
10. }
11. Object.prototype.push = function( value:Object ):void{
12. trace(’1st definition of push on Object:’ + value);
13. }
14. var a:Array = [];
15. a.push(‘foo’);
16. Array.prototype.push = function( value:Object ):void{
17. trace(’2nd definition of push:’ + value);
18. }
19. a.push(‘foo’);
20. delete Array.prototype.push;
21. a.push(‘foo’);
22. }
23. }
24.}

You should be able to edit the __proto__ property to splice in new inheiritance on instances. Writing example.

It is so weird to have all this old knowledge come rushing back to relevance. prototype and __proto__ dear god. :)

__proto__ is gone in Tamarin engine. But there is reference to a ‘toPrototype’ method for get/set on chain.

Well AS3 was intended to span strict and dynamic development. Some like strict while some like dynamic.

After reading your post (great btw, very informative and well explained), I don’t think that dynamic programming is worth the performance costs.

I don’t know, maybe there’s some other weird pattern or instance where it’d work, maybe not… But def an interesting paradigm

No matter how you implement this, you need to be able to retrieve a discriminator (specifying what the Actor is to do) from a target instance. I was thinking that it was properly not a property of the target instance but rather of its class, and therefore, since static class properties are not inherited in AS3, the prototype would be good. But in fact making it an instance property of the target makes retrieval faster, and it’s also more general, because you can then set different discriminators in targets based on any criterion, not just the target’s class.