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 (<aha...@adobe.com.invalid>) 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" <greg.d...@gmail.com> 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 <aha...@adobe.com.invalid> > 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