>>Given some sort of native dependency management in the framework, do we
>>really need styles?
There is some overlap. The biggest problem is the hierarchical nature of
styling adds some complexity.
Mike
Notice: This transmission is intended only for the use of the individual or
entity to whic
>>My simple mind just can't understand why we need a sophisticated multi-step
>>plan or full dependency injection. Why can't a simpler substitution pattern
>>do the job?
Alex, first, I am not sure what you think is involved in the injection
solution, but I am not sure it is more complicated. T
On 09/02/2012 00:44, Alex Harui wrote:
I think the simplest is just adding a replaceInstance on mx.core.Singleton...
The replacement in Singleton is just reasonable if all static code was
actually handled within the singleton code. I tried to explain before:
there is more code in the statics th
On 2/8/12 7:33 AM, "Martin Heidegger" wrote:
> I am curious about the "simpler substitution": How would you do that in
> detail?
I think the simplest is just adding a replaceInstance on mx.core.Singleton
that dispatches an event with what got replaced.
And maybe some new list of mixins that g
On 08/02/2012 23:45, Alex Harui wrote:
My simple mind just can't understand why we need a sophisticated multi-step
plan or full dependency injection. Why can't a simpler substitution pattern
do the job?
The complexity always comes with the detail. I assume one could
summarize it with:
Mov
8 feb 2012 kl. 15.25 skrev Michael A. Labriola:
> I am going to provide a version of the framework and compiler with a
> swappable, minimalistic injection mechanism and perhaps some basic AOPish
> concepts like compile time mixins. [...] The biggest problem in this approach
> is actually thing
On 2/8/12 1:50 AM, "David Arno" wrote:
>> From: Alex Harui [mailto:aha...@adobe.com]
>> Sent: 08 February 2012 03:10
>>
>> ... And then there are some old singletons like EffectManager that still
> use
>> static methods, which should be using Singleton instead.
>>
>> And then there is the wh
>I could be wrong but I think the plan I wrote about was a step-by-step
>instruction to get rid of singletons using a intermediate service locator that
>can be dropped in the end.
>To me the first step is to get from "unit tests are impossible" (the current
>state of the framework) to "they are
On 08/02/2012 18:50, David Arno wrote:
Let's have that debate. Replacing static methods with singletons will
not improve the testability of the code. If those static methods are
deterministic and have no side effects, then they are fine as static
methods (and maybe could be turned into global f
> From: Alex Harui [mailto:aha...@adobe.com]
> Sent: 08 February 2012 03:10
>
> ... And then there are some old singletons like EffectManager that still
use
> static methods, which should be using Singleton instead.
>
> And then there is the whole debate about Singletons in general...
Let's have
On 2/7/12 10:49 PM, "Martin Heidegger" wrote:
>
> Uhm, how can folks help you?
>
Someday, after we get all the code in and test suites running, I hope to
spend 2 days/week on my whiteboard re-write, 3 on shorter term improvements
that folks want including reviewing commits and patches. We'
On 08/02/2012 15:31, Alex Harui wrote:
You can have a back-door to replace singletons if you want to. That's even
easier to add to Singleton. For now though, keep in mind that because of
the stew of dependencies between classes in the framework, you really need
to restart the app or implement a
You can have a back-door to replace singletons if you want to. That's even
easier to add to Singleton. For now though, keep in mind that because of
the stew of dependencies between classes in the framework, you really need
to restart the app or implement a reset protocol, otherwise something migh
On 08/02/2012 15:02, Alex Harui wrote:
One way is to define another set of mixins that get initialized before
the SystemManager starts registering singletons.
In my whiteboard re-write, the Singletons will probably be defined in
some manifest, will only register just before first use, and there
On 2/7/12 8:42 PM, "Martin Heidegger" wrote:
> This second part is the reason I wrote this. I am all ears as to how
> this can be fixed more easily!
One way is to define another set of mixins that get initialized before the
SystemManager starts registering singletons.
In my whiteboard re-writ
On 08/02/2012 12:09, Alex Harui wrote:
I don't understand what this does other than what mx.core.Singleton already
does.
Actually there are two points: If you saw the small sample code: The use
of mx.core.Singleton is not just a simple redirect,
if (!_embeddedFontRegistry && !noEmbeddedFont
>
> There's a reason why IoC containers like SwiftSuspenders have a
> mapSingleton() method,...
>
And when I said that I actually meant the injector in Robotlegs:
https://github.com/robotlegs/robotlegs-framework/blob/8340bfda8d4e60a39617303a5fd09c4183c61de6/src/org/robotlegs/core/IInjector.as
-om
>
> And then there is the whole debate about Singletons in general...
> --
> Alex Harui
> Flex SDK Team
> Adobe Systems, Inc.
> http://blogs.adobe.com/aharui
>
>
I don't think the issue a lot of devs have with Singletons is actually with
the concept of Singletons itself but the implementation in wh
On 2/7/12 12:11 PM, "Martin Heidegger" wrote:
> Hello List,
>
> when thinking about unit testing of Flex components I got a strong
> argument against it due to the heavy use of Singletons throughout the
> project. I think I might have a good refactoring path to ease the
> transition from the
>The dependency injection requires to rewrite a lot without having unit test on
>the way. I think at the end of mentioned process we could simply switch to a
>DI model.
To me it looks like the opposite. I think the amount of rewrite here would be
more than injecting dependencies. Just my though
On 08/02/2012 05:20, Michael A. Labriola wrote:
Or, if you were going to go through all of that refactoring, you could
use a dependency injection rather than service locator pattern
The dependency injection requires to rewrite a lot without having unit
test on the way. I think at the end of men
>>when thinking about unit testing of Flex components I got a strong argument
>>against it due to the heavy use of Singletons throughout the project. I think
>>I might have a good refactoring path to ease the transition >>from the
>>current code to a code that might be easier manageable.
Or, if
Hello List,
when thinking about unit testing of Flex components I got a strong
argument against it due to the heavy use of Singletons throughout the
project. I think I might have a good refactoring path to ease the
transition from the current code to a code that might be easier manageable.
T
23 matches
Mail list logo
