I’d be wary of taking out removeBead. The bead lifecycle is pretty basic, and
I’m not sure PAYG should be applied to that.
I didn’t run into any scenario, I just noticed the following code in Strand.as:
public function set model(value:IBeadModel):void
{
if (_model != value)
{
addBead(value as IBead);
dispatchEvent(new Event("modelChanged"));
}
}
and in addBead():
if (bead is IBeadModel)
_model = bead as IBeadModel;
If for some reason two model beads are added, the second one will be the model,
and the first one will just sit there (hopefully inactive).
I’m not sure if this is a problem.
> On Aug 7, 2017, at 9:55 PM, Alex Harui <aha...@adobe.com.INVALID> wrote:
>
> I would not expect a need to switch models at runtime, so clean up after
> removal shouldn't be needed. Honestly, I'd try to prevent any beads from
> being swapped at runtime unless you are willing to pay for the cost. I've
> been thinking we should take out the removeBead API. What kind of
> scenario did you run into?
>
> I can't immediately think of what a model needs to listen to, but maybe
> there are scenarios I'm not thinking of.
>
> My 2 cents,
> -Alex
>
>
>
> On 8/7/17, 11:00 AM, "Harbs" <harbs.li...@gmail.com> wrote:
>
>> Studying the bead architecture it looks to me like IBeadModels should
>> never attach event listeners.
>>
>> (Strand allows for setting a new model and does not allow for cleaning up
>> event listeners on the old model.)
>>
>> Is that right?
>
