On 12/16/16, 10:14 AM, "[email protected] on behalf of Carlos Rovira" <[email protected] on behalf of [email protected]> wrote:
>Don't if what I want to propose is what others came above but hope that >helps: > >What about add ALL beads first and then process all beads? If code that >setup the bead is run when we have all in the array, the "getBead" method >would work. >Then make a queue and we could have a "isSetUp", if requested bead was not >setup could go to the end of queue and process the following and so until >all is processed > >Don't know if what I'm propossing is absurd or not in the actual ARQ of >strand-beads, but I think that some kind of process like this that ensures >the order is not important would enhance the concept of beads a lot. Fundamentally, assuming order is more efficient that not assuming order. IMO, it isn't that much harder than remembering the order of the booleans on the Event constructor. If you have to walk the array twice, once to add them and once to init them, that is more work than going through it once. We can provide tooling and debug-mode beads to help you get it right, but I don't like the idea of making the production version run code that isn't needed. IMO, not having good optimized production code is one of the reasons Flex did not get the traction it needed to remain popular. Folks are welcome to create beads that don't care about order, but the most Basic beads should since they are trying to be the smallest and fastest. -Alex
