On 1/31/12 1:37 AM, "Avinash Narayanan" wrote:
> @Alex : I know this is old but I've not been able to catch up with my
> email. What I wanted to ask you is, how can I help? with the start from
> scratch initiative.
>
> Thanks
> Avinash Y
>
>
Probably the best way is to get caught up on the
@Alex : I know this is old but I've not been able to catch up with my
email. What I wanted to ask you is, how can I help? with the start from
scratch initiative.
Thanks
Avinash Y
On Wed, Jan 25, 2012 at 1:20 PM, Haykel BEN JEMIA wrote:
> On 25 January 2012 08:32, Alex Harui wrote:
>
> >
> >
>
Hi everyone,
I've posted the sources here : https://github.com/badu/SparkOnly . Please
let me know if you find orphaned classes and eventually the results of your
experiments.
Best regards,
Bogdan
he same finding than me ?
>
>
> #Andres Lozada, I didn't follow the approach you mentioned in my try at
> the moment but it is the one I thought to try too in a full dev.
>
>
> Frédéric Thomas
>
> -Message d'origine----- From: Alex Harui
> Sent: Wednesday
Hi Shigeru,
I'm not a commit-er yet. Will publish (as I've said) when I have build
tasks and instructions for them.
Best regards,
Bogdan
On Sun, Jan 29, 2012 at 10:59 AM, Pepe wrote:
> very interesting...
> Why don't you commit it as a branch?
> It should be able to be accessed from Flex users
s
-Message d'origine-
From: Alex Harui
Sent: Wednesday, January 25, 2012 11:10 PM
To: flex-dev@incubator.apache.org
Subject: RE: Flex 5 UIComponent - Behavior Pattern
-Original Message-
From: Haykel BEN JEMIA [mailto:hayke...@gmail.com]
Sent: Tuesday, January 24, 2012 1
very interesting...
Why don't you commit it as a branch?
It should be able to be accessed from Flex users in the world.
thanks
Shigeru Nakagaki
2012/1/29 Bogdan DINU :
> Hi everybody,
>
> I've used the weekend to remove backward compatibility with Flex 3.x and
> below from the framework. I'm c
Great job Bogdan,
I will definitely do some tests on some existing pure 4.x projects!
-Original Message-
From: Bogdan DINU
Sent: Sunday, January 29, 2012 9:21 AM
To: flex-dev@incubator.apache.org
Subject: Re: Flex 5 UIComponent - Behavior Pattern
Hi everybody,
I've use
Hi everybody,
I've used the weekend to remove backward compatibility with Flex 3.x and
below from the framework. I'm curious if there will be any speed
improvement compared with the current framework and consider that this
would represent a base for other experiments (for those of you that are
int
To the list owner, can we get a link in the footer to the list home, list
search and unsubscribe pages?
On Mon, Jan 23, 2012 at 1:59 PM, Alex Harui wrote:
>
> Again, most of this has been discussed in prior threads.
>
> --
>
I agree with this, Flex 3 and Flex 4 should be kept apart and in my view
both moving to Apache and starting a fresh is as good as time as any to
trim away the fat as it's something I believe will be harder once you
release a build that people actually start using then you are stuck
maintaining that
I didn't mind backward compatibility even at Flex 4.
But they left it. I guess there were some big voice.
Current UIComponent is very fat.
I believe dropping backward compatibility is neccesary in order that
Flex evolves.
New architecture and new component model are welcome.
thanks
Shigeru Nak
> -Original Message-
> From: Haykel BEN JEMIA [mailto:hayke...@gmail.com]
> Sent: Tuesday, January 24, 2012 11:51 PM
> To: flex-dev@incubator.apache.org
> Subject: Re: Flex 5 UIComponent - Behavior Pattern
>
>
> This looks very bad. It looks like often used featur
Hi all,
This is a good topic and with your permission I would like add some ideas:
1) About closures, you can solve this with this having only one reference
to the behaviour, don't use closures, when you need call any function you
call from the behaviour reference:
function foo():void {
behavi
On 25 January 2012 08:32, Alex Harui wrote:
>
>
>
> On 1/24/12 11:24 PM, "Haykel BEN JEMIA" wrote:
>
> > Alex, you say the prototype was not faster, I suppose this is the case
> when
> > all features are enabled which is actually a good result (if it's not
> > slower). But the idea is that appli
On 1/24/12 11:24 PM, "Haykel BEN JEMIA" wrote:
> Alex, you say the prototype was not faster, I suppose this is the case when
> all features are enabled which is actually a good result (if it's not
> slower). But the idea is that applications almost never require all
> features.
I disabled all
Alex, you say the prototype was not faster, I suppose this is the case when
all features are enabled which is actually a good result (if it's not
slower). But the idea is that applications almost never require all
features.
Regarding backward-compatibility, if it will prevent innovation, what abou
e-
> > From: Alex Harui [mailto:aha...@adobe.com]
> > Sent: Tuesday, January 24, 2012 12:32 PM
> > To: flex-dev@incubator.apache.org (mailto:flex-dev@incubator.apache.org)
> > Subject: Re: Flex 5 UIComponent - Behavior Pattern
> >
> >
> >
> >
> &
esday, January 24, 2012 12:32 PM
> To: flex-dev@incubator.apache.org (mailto:flex-dev@incubator.apache.org)
> Subject: Re: Flex 5 UIComponent - Behavior Pattern
>
>
>
>
> On 1/24/12 10:20 AM, "Haykel BEN JEMIA" (mailto:hayke...@gmail.com)> wrote:
>
@incubator.apache.org
Subject: Re: Flex 5 UIComponent - Behavior Pattern
On 1/24/12 10:20 AM, "Haykel BEN JEMIA" wrote:
> I'm curious to see your work Alex. Were you able to do some
> performance and memory tests with your prototype?
>
> Haykel
Further back in th
On 1/24/12 10:20 AM, "Haykel BEN JEMIA" wrote:
> I'm curious to see your work Alex. Were you able to do some performance and
> memory tests with your prototype?
>
> Haykel
Further back in this thread I stated that the prototype was not faster
because of 'interstitial' costs: the cost of addin
I'm curious to see your work Alex. Were you able to do some performance and
memory tests with your prototype?
Haykel
On 24 January 2012 19:17, Alex Harui wrote:
>
>
>
> On 1/24/12 10:09 AM, "Haykel BEN JEMIA" wrote:
>
> > Just looking at the interfaces UIComponent implements I can see some
On 1/24/12 10:09 AM, "Haykel BEN JEMIA" wrote:
> Just looking at the interfaces UIComponent implements I can see some
> candidates for implementation as behaviors (besides the ones suggested by
> Tink):
>
> public class UIComponent extends FlexSprite
> implements IAutomationObject, IChild
Just looking at the interfaces UIComponent implements I can see some
candidates for implementation as behaviors (besides the ones suggested by
Tink):
public class UIComponent extends FlexSprite
implements IAutomationObject, IChildList, IConstraintClient,
IDeferredInstantiationUIComponent,
Hi Tink,
with all the feedback I've got, I'm now thinking that we should make
behaviors out of things that can be considered secondary, like scrolling,
mouse input, re-sizing, tool-tip (and all your list). A good way would be
to separate core aspects from secondary ones and those extras to become
On 23 Jan 2012, at 17:08, Bogdan DINU wrote:
Hey Jonathan,
I'm convinced about my idea. However, I cannot start developing
while I
don't have the whole picture, a plan and a road map. And having a
whole
picture is everything. Look at how Doug challenged me as Devil's
advocate :)
A bit
On 1/23/12 12:05 PM, "Ryan Frishberg" wrote:
> I understand that caching every function would be expensive, but I don't
> understand why a reference to a function isn't just 4 bytes. Why is it a
> closure? The only thing I can think of that would be in scope would be the
> "this" object for
> Actually, that makes it worse, espeically from a memory standpoint. Every
> cached function reference is just making the allocation size of the
> UIComponent larger and more inefficient. And, a function reference itself
> is some 100 bytes or so because it is a closure, not a pointer into code.
On 1/23/12 10:19 AM, "Bogdan DINU" wrote:
> you haven't answered my reply question : "what should we favor ?
> Inheritance ?Composition ?". I would really love an answer :)
I think we want to use more composition in the future, but keep in mind that
MXML leverages inheritance.
Again, most of
On 1/23/12 10:31 AM, "Doug McCune" wrote:
> Alex, first, thanks for that memory breakdown, very helpful.
>
>
>> The issue was not in the cost of the
>> allocations, it was in the cost of an additional function call to run the
>> actual work. Everything is now being proxied.
>
>
> What if
It would be great if it was a blank slate without backwards compatibility
worries. I for one don't mind just using 4.6 and fixing bugs but for a new
project I could see many people being happy upgrading to a fresh new
framework where lessons from the past few years have been applied without
the blo
Alex, first, thanks for that memory breakdown, very helpful.
> The issue was not in the cost of the
> allocations, it was in the cost of an additional function call to run the
> actual work. Everything is now being proxied.
What if when setting the composited piece you always stored a hard
ref
On Mon, Jan 23, 2012 at 10:19 AM, Bogdan DINU wrote:
> Hey,
>
> you haven't answered my reply question : "what should we favor ?
> Inheritance ?Composition ?". I would really love an answer :)
>
There is no black or white answer. Each decision on whether to inherit or
compose features will have t
On 1/23/12 8:43 AM, "Doug McCune" wrote:
> Just one counter-thought to play devils advocate a bit. One thing you have
> to consider is performance, especially on something like UIComponent that
> drives every little thing in your app. And in general, creating lots of new
> Objects is slow (and
Hey,
you haven't answered my reply question : "what should we favor ?
Inheritance ?Composition ?". I would really love an answer :)
Now, those Spark "things" are dependent on whom has the "teacher" and why
they did it like that. I have nothing to confess, but the fact that in my
company everythin
Jonathan,
please forgive me if I had offended you in any way. However, with the risk
of repeating myself, until lately (to be read one year) I had no idea what
[Frame(factoryClass="mx.managers.SystemManager")]
really does in our beloved framework. I'm just looking for people to
support such idea a
>
> But then, why we are on the mailing list? To find solutions.
>
Agreed, and I'm all for everyone trying things out. As was pointed out
earlier: nobody needs consensus to commit code to their whiteboard.
> Spark is faster then Halo, just because a small change in terms of
> thinking :) isn't i
Hi Doug,
I'm so much pleased that you are the devils advocate. The point of view you
have presented is somehow a trap - I'll explain this in the end of my reply.
I must agree with your point of view : creating is slow, destroying is even
slower. But then, why we are on the mailing list? To find s
On Mon, Jan 23, 2012 at 11:08 AM, Bogdan DINU wrote:
> I'm convinced about my idea. However, I cannot start developing while I
> don't have the whole picture, a plan and a road map. And having a whole
> picture is everything. Look at how Doug challenged me as Devil's advocate
> :)
>
I understand.
Hey Jonathan,
I'm convinced about my idea. However, I cannot start developing while I
don't have the whole picture, a plan and a road map. And having a whole
picture is everything. Look at how Doug challenged me as Devil's advocate :)
On Mon, Jan 23, 2012 at 5:38 PM, Jonathan Campos wrote:
> On
Just one counter-thought to play devils advocate a bit. One thing you have
to consider is performance, especially on something like UIComponent that
drives every little thing in your app. And in general, creating lots of new
Objects is slow (and disposing of them can also be slow due to the GC).
Ov
On Mon, Jan 23, 2012 at 2:32 AM, Bogdan DINU wrote:
> Please let me know if you know any drawbacks that you can foresee.
As with everything, get developing and see if others catch onto your idea.
--
Jonathan Campos
Sorry for the double post, for some reason Outlook sent the email even
though I didn't hit the send button!
Wael
On 23/01/2012 11:37, "Wael Jammal" wrote:
>+1 for this, I can think of many cool things to implement in my framework
>using Behaviours.
>
>wael
>
>On 23/01/2012 11:01, "Bogdan DINU"
+1 for this, I can think of many cool things to implement in my framework
using Behaviours.
wael
On 23/01/2012 11:01, "Bogdan DINU" wrote:
>Thank you for your input Haykel! I'm very pleased to hear that it worked
>well for you and you're happy with the results.
>
>On Mon, Jan 23, 2012 at 12:55
+1 to this as well, would open up many new doors for those like me who
enjoy working on their frameworks :)
Wael
On 23/01/2012 11:01, "Bogdan DINU" wrote:
>Thank you for your input Haykel! I'm very pleased to hear that it worked
>well for you and you're happy with the results.
>
>On Mon, Jan 23
Thank you for your input Haykel! I'm very pleased to hear that it worked
well for you and you're happy with the results.
On Mon, Jan 23, 2012 at 12:55 PM, Haykel BEN JEMIA wrote:
> I also find that the Behavior pattern is a powerful way of making
> components much lighter, more configurable and e
I also find that the Behavior pattern is a powerful way of making
components much lighter, more configurable and easier to extend and
customize. I have used this pattern in one of my last Flex projects to
create different versions of the same application with different features
(features are implem
This is not only about accessibility. It's about everything : behavior
classes would be specialized in one and one only. I'm writing a new blog
post right now, expanding the benefits that I've presented to you.
On Mon, Jan 23, 2012 at 12:12 PM, Giorgio Natili wrote:
> >Benefits :
> >
> >1) mainta
>Benefits :
>
>1) maintaining inheritance with older versions of SDK while writing an
>entirely new framework;
>2) lightweight components based on UIComponent;
>3) lightweight jobs for sdk managers;
>4) smaller memory foot print compared to previous versions;
>5) high customization of components fo
Hi Giorgio,
by having separate classes for dealing with specialized behaviors, I think
UIComponent will become very flexible and instead of extending UIComponent
we would just add certain behaviors to it, composing rather than extending.
Benefits :
1) maintaining inheritance with older versions
Hi Bogdan,
In your post you refer to this implementation as useful from an
accessibility point of view, can you clarify what do you mean exactly and
which are the benefits you see in this field?
You don't thing the pattern you described is very similar to traits?
Giorgio
On 1/23/12 9:32 AM, "Bog
51 matches
Mail list logo
