Hi all,
This is a good topic and with your permission I would like add some ideas:
1) About closures, you can solve this with this having only one reference
to the behaviour, don't use closures, when you need call any function you
call from the behaviour reference:
function foo():void {
behaviourReference.foo();
}
You can use the chain responsibility pattern.
2) Is not necesary create a behaviour object for each UIComponent that
requiere one. It can be a pool of object, for example: at startup, it can
be created 10 FacusBehaviour objects, and each UIComponente get one of them
when it needed, and dispose later. On this way the objects are shared for
all UIComponents and new objects are created only when those first 10
objects are not enough.
Is important to find the best strategy to get and free faster this shared
object. Maybe with a function like invalidatesProperties() but, I don't
know... invalidateBehavoiur() and it make call a commitBehavoiurs() in the
next render time... like its works commitPropeties or updateDisplayList...
//inside UIComponent
poolBehaviours.get(FOCUS_BEHAVIOUR).foo();
I don't know, those are only a few ideas....
Thanks!!!
2012/1/25 Haykel BEN JEMIA <hayke...@gmail.com>
> On 25 January 2012 08:32, Alex Harui <aha...@adobe.com> wrote:
>
> >
> >
> >
> > On 1/24/12 11:24 PM, "Haykel BEN JEMIA" <hayke...@gmail.com> wrote:
> >
> > > Alex, you say the prototype was not faster, I suppose this is the case
> > when
> > > all features are enabled which is actually a good result (if it's not
> > > slower). But the idea is that applications almost never require all
> > > features.
> > I disabled all but about 8 or so 'behaviors' it needed and it was still
> > slower. The interstitial time of the required often-used 'behaviors'
> make
> > things slower. Most of the stuff you'd disable doesn't really take that
> > much time in small apps.
> >
>
> This looks very bad. It looks like often used features must be implemented
> through inheritance.
>
>
> > >
> > > Regarding backward-compatibility, if it will prevent innovation, what
> > about
> > > working on a new version that is not backward-compatible in parallel to
> > the
> > > standard version? Existent applications continue to use the standard
> > > version which will be maintained with bug fixes and perhaps also some
> new
> > > features and when the newer version is out, let's say Apache Flex X
> (for
> > > 10), new applications will use it and old applications can be ported
> (but
> > > not required).
> > That is the plan. I hope to 'start over' on my whiteboard.
> >
> >
> Good news!
>
>
> > --
> > Alex Harui
> > Flex SDK Team
> > Adobe Systems, Inc.
> > http://blogs.adobe.com/aharui
> >
> >
>
--
Andrés Lozada Mosto
