Nicolas Cannasse ncannasse at
Fri Jun 30 00:29:36 PDT 2006

> Nicholas, what is your view of how reflection is implemented in AS3?
> That is, as an XML dump of the object's traits table. AS3 reflection
> has a dependency on e4x, of course, which might be problematic since
> e4x is an optional extension. But I likewise feel that Reflection
> should, in any case, be an optional extension, as opposed to part of
> the core language.

There is two kind of reflections :

a) accessing the class metadatas + fields types at runtime. This is what
AS3 is doing. It's of course possible since all theses infos are present
in the SWF9 binary format, and are needed by the JIT to perform
appropriate optimizations. This is not what haXe is doing. Only some
metadatas are accessible at runtime, like the class name and the
inheritance tree.

b) an API to access objects in an abstract manner. See

> Do you have a criticism of AS3's Proxy class? Personally, I think it
> is cleaner and more transparent. 

You have to "extend" Proxy to get the __resolve. I think that's a very
bad design since with single inheritance you cannot add a __resolve by
extending another class. That means you have to choose either Proxy or
Subclass. If Proxy was an interface that would have been possible...

> However, it could do with some
> extension to bring the functionality up to the same level (that is,
> being able to essentially turn any existing dynamic object into a
> proxy). For that, Proxy would have to be made a special case for
> compile-time type-checking and have the ability to override the "as",
> "is" and "instanceof" operators (and probably others).

Yes, this is what haXe Proxy is doing. But since there is no __resolve
support (or equivalent) on all platforms, it's restricted to method calls :

for a quick example.


More information about the Es4-discuss mailing list