Currently "has" is getBeadByType(ISomeInterface). I personally don't want to spend the energy adding a new keyword to the language. Also, this kind of "has" is not the same as "hasOwnProperty". This is more about composition, not what properties exist.
My first proposal for optimization is to create Language.has as a utility function that we could later optimize. getBeadByType must always scan the strand and use "is", but Language.has can try caching, or a faster test, such as assuming that beads that support "has" will support some sort of id map API that can be queried in a try/catch. That might be faster than sequential "is" checks. -Alex On 1/16/20, 7:05 AM, "Harbs" <[email protected]> wrote: I like the idea of a “has”. What would the syntax be and how would it work? I’d love to be able to write if(foo has Baz) (and that would be compiled to something like if(Language.has(foo,Baz)) I’d also guess that it would loop through the list of beads and test “is” on all of them. For positive results, I think we could make that fast with a cached lookup after the first time, but for failed checks, I imagine it would be quite slow. > On Jan 16, 2020, at 8:20 AM, 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 >
