I know there have been other responses, but I think this original post is the best place for my response.
IMO, sealed classes are another safety/security measure. Changing the code in a class at runtime invites opportunities for hacking that are really hard to detect. The set of beads assigned to a strand would be instantiated in the constructor if we could do it that early, but we want to allow someone to declare options/overrides of default behavior and the only practical way to do it is to wait a bit. But once the instantiation lifecycle is over, you really should be able to examine what the instance is composed of. It shouldn't change later. Later changes create all kinds of havoc for code coverage tools, debugging, and other productivity issues. So, IMO, it is best to try to make the composition of an instance declarable at author-time. If you need to specify something for an inner child, we have ways of doing that. ItemRenderers specify the inner children of a list. A Panel's TitleBar can be swapped for a different titlebar. If you want a component that can switch between laying out horizontally and vertically, you could use states or other techniques to swap between a child with HorizonalLayout and a child with VerticalLayout, but changing a single child's beads at runtime is not a best practice. You could also create a VerticalOrHorizontalLayout bead. All of these techniques make it easier to see at author-time what the pieces are. That way, when debugging into the child where the MXML/CSS said HorizontalLayout and you see a VerticalLayout, you are less likely to be surprised and think there is a bug in the layout assignment when there isn't. And thus, because of PAYG, none of our existing beads carry code around to cleanup if removed from the strand, and I've mentioned recently that I seriously considering we should take removeBead out of IStrand and UIBase. However, I agree with whoever responded that we shouldn't block bead removal. We should just make it a truly rare occurrence. Somebody, some day, will come up with a rare reason to need it. But they will need to use beads that carry extra code that does the clean up and call some utility function that removes the bead from the strand. So, I don't fully understand this scenario and am too backlogged to really dig through it, but please first attempt to find patterns that allow specification of the children and their layout at author-time. Think of beads as an instantiation-time composition of a class instance. Then consider beads that can go "both ways". Then consider beads that can be removed. But for PAYG reasons, we don't want to have all beads know how to be removed. My 2 cents, -Alex On 1/27/19, 12:26 AM, "Carlos Rovira" <[email protected]> wrote: Hi, Piotr and I found a situation where we don't know how to solve with some generalist solution. Hope others here could give some ideas. The setup: We have a layout bead that decorates the strand with a css class selector. The bead is configured in CSS as a default bead The problem: We found that adding another layout bead at runtime that "substitute" the default bead and adds other CSS class selector, left the selector(s) from the old layout bead untouched. Notice that adding the new layout bead in MXML through beads array is ok, since (I think) default bead is never instantiated and the second one is the only one running its code. The problem happens if we try to do the change at runtime at a later time. So, our question is: How to deal with beads that are already instantiated and needs to be removed. How we should operate with it? Should be have some removal mechanism in Royale to do this? For more info and code about this issue, Piotr shared some source code in other recent thread about Jewel Group. Thanks -- Carlos Rovira https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C4278c26f3fb142d3b1d208d684311fa0%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636841743883902882&sdata=K%2FN1izFMjQXpGQcGZfraUdrXYPuYniimcF5i0dKe1i8%3D&reserved=0
