Hi,
recently I want to do a "has" instead of "is", but I couldn't.
I'm not talking about at "bead" level, just something like we use to do in
Flash (hasOwnProperty)
Taking the code in [1]. I'd like to change this
if(!(_strand is IDataGridColumnList))
for something like this
if(_strand.hasOwnProperty("datagrid"))
in order to avoid check against the IDataGridColumnList interface, that
users using List but not using DataGrid, will not need to compile in his
apps (adding all that datagrid code burden)
[1]
https://github.com/apache/royale-asjs/blob/56dbe7a33e66f104a882654ce00c7a1074296725/frameworks/projects/Jewel/src/main/royale/org/apache/royale/jewel/beads/itemRenderers/AddListItemRendererForArrayListData.as#L154
El jue., 16 ene. 2020 a las 7:44, Alex Harui (<[email protected]>)
escribió:
> You are welcome to try and see how many cache hits it gets. I think in
> renderers, we ask once per renderer. I'm not sure there is a faster way to
> do the first lookup of "is", but for "has" we could change the lookup and
> save time.
>
> On 1/15/20, 10:38 PM, "Greg Dove" <[email protected]> wrote:
>
> For the 'something is ISomeInterface'
> I had wondered in the past if these types of lookups could be
> incrementally
> cached on the 'is' target (after first lookup), that might make sense
> for
> interfaces, which are the deepest checks I think?
> caching result (could optionally create the Map)
> ISomeInterface['implMap'].set(something.constructor, isResult )
>
> then earlier in the interface checks, it could do something like:
> if (ISomeInterface['implMap'] &&
> ISomeInterface['implMap'].has(something.constructor) ) return
> ISomeInterface['implMap'].get(something.constructor)
>
> I realize its extra code, but it should be quite a bit faster over
> time I
> think.
>
> On Thu, Jan 16, 2020 at 7:20 PM Alex Harui <[email protected]>
> wrote:
>
> > Hi,
> >
> > Several different threads have brought up issues with sharing code
> between
> > component sets. Other threads have offered different and clever
> ways to
> > do various things like how MXML is applied to a component.
> Meanwhile, over
> > in MX emulation, I was starting to copy some code from Basic to
> MXRoyale to
> > get the various MX components to be valid item renderers. MXRoyale
> is
> > using Basic's item renderer architecture which is better
> encapsulated: the
> > renderer draws its hovered and selected state. In Flex, the List
> draws
> > over the renderer, which makes it hard to customize the way the
> renderer
> > will look when hovered and selected.
> >
> > It finally occurred to me that one of the reasons we end up copying
> code
> > is because we are still using too many "is" checks instead of "has"
> > checks. I'm not even sure we have any "has" checks in the Royale
> > framework. I was afraid of the overhead of a "has" check, but I'm
> starting
> > to change my mind because:
> >
> > 1) The "is" check actually runs a fair amount of code, especially for
> > (comp is ISomeInterface)
> > 2) The length of bead arrays don't seem too long.
> >
> > A "has" check calls getBeadByType(ISomeInterface), so it actually
> will run
> > the (bead is ISomeInterface) on potentially the entire strand
> array/vector,
> > although we could speed that up by annotating beads or keeping track
> of
> > what is on the strand. But the code sharing/reuse potential of this
> > pattern seems significant to me.
> >
> > For example, it could change how hard it is to make a component
> usable as
> > a top tag in MXML. Instead of the component having to implement
> certain
> > methods, the component could have a bead installed and the
> > MXMLDataInterpreter could talk to that bead instead of the component.
> >
> > In the case of the item renderers, instead of testing if the
> renderer "is"
> > ISelectableLIstItemRenderer, it could ask if the created widget
> "has" an
> > ISelectableLIstItemRenderer bead and the logic in that bead can be
> reused
> > in both Basic and MXRoyale without being copied.
> >
> > Some code, like Container overrides of addElement probably can't be
> > refactored into a "has". But I wonder how many other things could.
> I'm
> > not sure I would move everything that could be moved into a shared
> bead.
> > We'd have to think about the overhead on small components and apps.
> But
> > for MXML support and Item Renderer support, it seems to make sense.
> >
> > Anyway, I will look into refactoring the item renderer code in a
> few days
> > unless feedback indicates otherwise. Bugs like #676 and #681
> inspired this
> > post.
> >
> > Of course, I could be wrong...
> > -Alex
> >
> >
>
>
>
--
Carlos Rovira
http://about.me/carlosrovira
