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.
