So to sum up this slightly off-topic discussion, instead of JewelGroup implementing IClassSelectorListSupport we can have a bead called ClassSelectorListSupport.
Application developers will be able to call group.getBeadByType(IClassSelectorListSupport) as IClassSelectorListSupport).addClass() or if declared with <Group><beads><ClassSelectorListSupport id=”classSelectorSupport”/></beads></Group>, simply classSelectorSupportList.addClass(). We expect a dev team using Royale to have some knowledge about beads and strands so they can create TLCs for the application developers which will make this even simpler and more Flex/Express like. I still have a feeling newcomers to Royale will be asking for readymade TLCs and that it’s important to have them available. Whether or not they should be an included in the SDK I’m not sure. Different topic I suppose. ________________________________ From: Alex Harui <[email protected]> Sent: Monday, May 6, 2019 6:48:18 PM To: [email protected] Subject: Re: Using @extrens ( RE: Example of access external JS using Apache Royale) Hi Yishay, IMO, there are application developers (users) and component developers. Some folks will be both. Component developers do pay for lots of things in Royale in order to make reusable components. We do want to make it easy for application developers can make "one-off" components. Component developers will have to understand composition vs inheritance, PAYG, and if we're lucky, cross-platform/runtime differences. And we want the component developers to do that to make life easier for the application developer. The application developer should be able to call tlc.method() almost all of the time because enough people needed to call (strand.getBeadByType(Functionality) as Functionality).method() so frequently that some component developer took the time to create a TLC and proxy that call to the API surface. If you look at our TLCs today, that's pretty much all they do. Royale is essentially about finding the repeating patterns that application developers need and packaging them up in a way that improves their productivity. The cool thing is that the application developer can re-compose the beads in a component if they need to in MXML and then access the bead directly just by giving it an id/localid. They won't really need to call getBeadByType. <js:TLC> <js:bead> <js:ReplacementModel id="replacementModel" /> ... </js:TLC> <fx:Script> replacementModel.data = "foo"; </fx:Script> No need to learn how to subclass or take the time to subclass something just to re-compose a single instance of something. Plug-in the replacement, give it an id and continue on. If IDE's can't code hint that today, I think they should be able to. It is pretty explicit/declarative, and we can add metadata to enhance code-assist at no cost to runtime. I don't understand your argument about null checks. IMO, even "is" tests have to check for null. If your point is that we can use @royaleignorecoercion to skip the "is" tests, then yes, that's true. Composition does have a cost. Things composed of lots of little pieces will weigh more than the thing with everything mixed together, but you can always inline the beads to save on those costs. As a reminder, the reason I am so picky about PAYG and composition is because I watched Flex suffer from the lack of PAYG and loose-coupling and composition and I do not want us to go down that road again. HTH, -Alex On 5/5/19, 11:44 PM, "Yishay Weiss" <[email protected]> wrote: I understand that this is PAYG in terms of code size. My concern is that we’re paying in other ways for this composition pattern. We’re reducing code size but increasing complexity (user needs to check for null before calling a method). Also, IDEs may have a hard time hinting for beads that may or may not exist. I agree that the performance issue can probably be mitigated with caching or something. I’m raising this issue so we can agree on a way to write components. Should users be expected to make calls with (strand.getBeadByType(Functionality) as Functionality).method() or tlc.method(). I’m pretty sure users will prefer the latter so I guess the compromise is to create TLCs that internally load beads. Thoughts? ________________________________ From: Alex Harui <[email protected]> Sent: Monday, May 6, 2019 9:02:18 AM To: [email protected] Subject: Re: Using @extrens ( RE: Example of access external JS using Apache Royale) IMO, it is PAYG. There is no cost until you use it, since getBeadByType is part of the IStrand implementation. In a true implementation, you would test for animateBead == null if you expect that it can be null, since that would be handling the "has not" case. If your concern is performance, as in, how slow is it to call getBeadByType()? That's a different and legitimate question. I'm mainly trying to point out that the "has" question is possible in a composition-oriented framework and is more flexible than requiring "is" (which results in increased code size as the TLC has to implement some interface. The performance hit would depend on how many places in the code need to ask "has" and how often. It might be/should be possible to optimize IStrand if we know that getBeadByType is being called often, with the usual trade-offs on code size. All we need is some folks to try it and do some measurements. My 2 cents, -Alex On 5/5/19, 5:03 AM, "Yishay Weiss" <[email protected]> wrote: >if you can get yourself away from trying to access features on concrete instances (…) >var animateBead:IAnimateBead = indicator_content.getBeadByType(IAnimateBead); >animateBead.animate(); Is this PAYG? getBeadByType iterates through an array. Also, animateBead may turn out to be null which adds a level of uncertainty as to whether or not this will run.
