On 6/25/12 10:06 AM, "Roland Zwaga" <rol...@stackandheap.com> wrote:
>>
>> How much freedom do we have?
You have lots of freedom. Often there is more than one way to solve a
problem and by being first to suggest a solution, you get to put a stake in
the ground, and I know I am less likely to want to change something that is
already coded vs some plan that hasn't been coded.
>> Marking it public is fine, using a getter is
>> fine, adding a setter is fine as well.
FWIW (and IMO), EffectManager also need to be refactored to use the "newer"
Singleton pattern (a static class that creates an impl instance that uses an
interface, e.g: StyleManager, CursorManager, etc). This would mean that you
need getter/setter pairs instead of static var.
>>
>> What about adding the effect instances to the effectsPlaying property on
>> EffectManager.effectStart() method? Would that have any adverse effect?
It would break any app relying on those properties only containing triggered
effects.
>> If
>> it did we could refactor effectsPlaying to triggerEffectsPlaying and use
>> effectsPlaying for normal effects (or normal and trigger) so the names
>> matche the descriptions.
Breaking backward compatibility is generally not a good idea, but there is
no strict policy against it.
>>
>> We could also dispatch an effectStart and effectEnd event from the
>> EffectManager class. Doing both would solve the problem of tracking
>> effects.
>>
>
> Haha, now we'll enter into an interesting API discussion potentially ;)
> Exposing the
> insides of the framework is not always preferable because you open yourself
> up to modification that is not always wanted. (well, its never wanted I
> guess,
> open to extension, closed to modification, anyone?) Exposing certain
> innards might
> get you into trouble when evolving the SDK. Once you make something public
> its not
> easy to go back in a later version.
Exposing the specifics of an implementation is generally not good, so my
'test' is more about the semantics of the change. IOW, would any effect
management implementation want to keep track of which effects are running?
I would say yes, and Mustella certainly needed it. So it isn't an
implementation detail, it is part of a design that allows for
diagnostics/analysis.
> If the property really just needs to be public for tracking usage, then I
> believe what Jude
> suggest about dispatching an event sounds like an elegant solution to me...
>
> Just my 2 cents...
>
> Roland
--
Alex Harui
Flex SDK Team
Adobe Systems, Inc.
http://blogs.adobe.com/aharui
