Spicefactory

nickrjensen · Joined: 21 Sep 2009 Posts: 2 Location: NYC

I have noticed some interesting behavior when sending and receiving messages from subclasses. Given the following context:

Jens Halm · Posted: Tue Sep 22, 2009 12:31 am Post subject:

It depends on how you configured the objects. If you are using [ManagedEvents] metadata tags you should be aware of the fact that those tags are not inherited. It's a quirk of describeType I cannot do much about. Parsing superclasses additionally is not an option due to performance reasons (just think about the hundreds of properties and methods of UIComponent which would be parsed multiple times then).

But this is just blind guessing since I don't know how you configured the sender. Unfortunately there are some severe limitations in describeType and also in the ApplicationDomain class which cause some trouble for IOC containers.

If I'm right with my guess there are only two workarounds: Repeat the [ManagedEvents] tag on the subclass or use the <ManagedEvents> MXML tag instead.
_________________
Jens Halm
Spicefactory

nickrjensen · Joined: 21 Sep 2009 Posts: 2 Location: NYC

Thanks for your reply. Repeating the [ManagedEvents] tag isn't really ideal - I'll probably resort to adding it to the Container.

I understand that traversing and parsing all the superclasses is not the right thing to do. But one thing still confuses me - It does seem like there is some level of class traversing going on with the Receiving end. In my example above the [MessageHandler] tag is decorating a function in the BaseReceiver class, but the class defined in the Container is Receiver, and yet the message is still received.

Jens Halm · Posted: Tue Sep 22, 2009 1:11 am Post subject:

Metadata on methods is available in subclasses as long as you do not override the method. In each case where you are not sure you could just call describeType(MyReceiverSubclass) and examine which tags are in there and which are not.

While thinking about it I realized that I might add a [InheritMetadata] tag to a future release (2.2 since 2.1 is almost done). This way you could explicitly instruct the container to parse the superclass too. As long as you don't use it on anything that extends UIComponent or any other dinosaur class performance should be okay then.
_________________
Jens Halm
Spicefactory

verveguy · Joined: 22 Sep 2009 Posts: 30 Location: Raleigh, NC

Jens,

I've done a fair bit of reflective type-tree walking (see xobj project on bitbucket) and found myself needing to aggressively cache the metadata obtained from types for performance reasons.

What reasons do you see why you couldn't do the same in this case and keep the extracted information cached against the type in a simple dict for fast access?

Jens Halm · Posted: Wed Sep 23, 2009 1:26 am Post subject:

In fact, this is exactly what I'm doing in the Spicelib Reflection API, just look into the ClassInfo class. It even caches per ApplicationDomain so that you can purge the reflection cache for a single domain in case you are unloading a module for example.

But... for UIComponents and other heavy classes describeType is so slow that even with caching it is virtually impossible to walk the full inheritance tree for components. Application startup would be unacceptably slow then. Even without walking the inheritance tree it is sometimes necessary to skip the regular Parsley view wiring if there are too many components which get wired at the same time. I got this feedback from several people working on large applications. This really is a deficiency of how describeType works and I cannot do much about it. The Flash Player definitely needs a fast and efficient Reflection API.
_________________
Jens Halm
Spicefactory