incubator-flex-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Left Right <>
Subject invalidateParentSizeAndDisplayList justification
Date Sun, 25 Mar 2012 20:38:30 GMT
Hello, I've been taking a more close look at the code and I found that this
particular function is used a lot (almost any other method or property that
has to do with graphical display of a component uses it to notify the
parent of the component about the change).
Here's the function itself:
    protected function invalidateParentSizeAndDisplayList():void
        if (!includeInLayout)

        var p:IInvalidating = parent as IInvalidating;
        if (!p)


Now, I can understand what purpose this function serves, but I also think
that it is a bad thing to do, and here is why:
- every child (especially bad if there are many) will cause parent's
revalidation - this is a situation prone to infinite validation loops, when
properties dealt with have rounding errors and parent will cause
repetitious validation of the children, while children will, in return
cause repetitious validation of the parent.
- it, out of nowhere assumes that the parent, in order to by notified about
the change must be an IInvalidating - what gives? This is one of the mostly
hated features of Flex framework. It never cares about any other code and
always assumes it lives alone in the application, so, no other container
having Flex framework display objects will not even have a chance to
interact with them in a proper way, because, obviously, it is not an may
not be an IInvalidating...

Normal approach to this problem would be to use events, or, if you are
concerned about performance, then use callbacks. I.e. a parent of this Flex
component would give a callback function to this component, which this
component would call once it updates itself. This is an idiomatic way for
other Flash classes to communicate: the child has registered a mouse click
- it sends an event to the parent, and the parent then may decide to handle
it, the child doesn't invokes parent's methods handling the click.

Now, this particular approach resulted in all kinds of ugly solutions like
this one for example:

    public function set depth(value:Number):void
        if (value == _depth)

        _depth = value;
        if (parent != null && "invalidateLayering" in parent &&
parent["invalidateLayering"] is Function)

Magic strings... not using interfaces... not handling potentially unsafe
reflection calls (what if invalidateLayering needs more arguments?) The
code like this earns bad name to the framework... but it's not an easy
patch. the invalidateParentSizeAndDisplayList is used something like 100
times in SpriteVisualElement alone, so, fixing this will require a forceful
decision. Since this function is protected, there's a chance people used it
/ have it overridden, so if it gets removed, it will cause compatibility

So, I'm asking what to do / is there any prepared course of action
regarding such situations, will we be able, and in what time, to deprecate
old features?



  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message