By all means do it and post it here. I'd rather have more interfaces with a
few more bytes and less dependences if I understand you correctly.
On Monday, January 16, 2012, David Arno da...@davidarno.org wrote:
From: Tink [mailto:f...@tink.ws ]
Sent: 16 January 2012 08:21
There is also a small
On 15 Jan 2012, at 22:23, David Arno wrote:
Tink, Jeffry,
Maybe I've got confused, but I was describing spark.components.List,
which I
assume is a spark component. This class might be less monolithic
than the
halo version, but it is ridiculous to claim it implements composition.
Take for
That is true. We won't be able to make changes to the classes built into
the
AVM.
Exactly the point I was talking about, that Apache community will be having
this limitation. Though such changes to native classes will be rare,
community might need them in future to modify.
--
Thanks,
Amit Goel
That is true. We won't be able to make changes to the classes built into
the
AVM.
Exactly the point I was talking about, that Apache community will be having
this limitation. Though such changes to native classes will be rare,
community might need them in future to modify.
I really don't
From: Amit Goel [mailto:agoel@gmail.com]
Sent: 16 January 2012 08:28
Exactly the point I was talking about, that Apache community will be having
this limitation. Though such changes to native classes will be rare,
community
might need them in future to modify.
If we target
From: Tink [mailto:f...@tink.ws ]
Sent: 16 January 2012 08:21
There is also a small amount of code the make sure the selected index or
carat is
visible (as a Scroller doesn't have any logic for selected items).
We clearly have very different ideas on a small amount of code.
David.
fair enough :)
On Mon, Jan 16, 2012 at 2:49 PM, David Arno da...@davidarno.org wrote:
From: Amit Goel [mailto:agoel@gmail.com]
Sent: 16 January 2012 08:28
Exactly the point I was talking about, that Apache community will be
having
this limitation. Though such changes to native
I can't tell if Amit is a strong Flex supporter (as stated in his email) or
if Amit thinks it is a lame SDK (as stated in his email). Either way, the
Apache Flex community will decide what the future of Flex will become, and
I have a strong feeling it will be with or without the AVM. Either way it
Well I think there might be other words to say it, but Adobe has to do that.
@Omar:
Sure we all need to stay positive about it. Apache Flex community will take
the Flex SDK forward, and the time is gonna tell that.
Long Live Apache Flex!
--
Thanks,
Amit Goel
On Sun, Jan 15, 2012 at 1:36 PM,
I have full faith on Apache Flex, but not on Adobe any more!
On Sun, Jan 15, 2012 at 1:45 PM, Amit Goel agoel@gmail.com wrote:
Well I think there might be other words to say it, but Adobe has to do
that.
@Omar:
Sure we all need to stay positive about it. Apache Flex community will
take
I have full faith on Apache Flex, but not on Adobe any more!
I don't really get the point of this thread, if you're talking about
runtime dependency its been discussed at great length - we're here to move
the Flex SDK forward not to bash Adobe.
Regardless of your opinion about Adobe, their
Amit,
I've voiced my concerns around the runtime a few times, both in the
incubator mailing lists, and in this mailing list.
http://old.nabble.com/-PROPOSAL--Flex-for-Apache-Incubator-to33005429.html#a33012665
http://markmail.org/search/?q=+list%3Aorg.apache.incubator.flex-dev+avm
Roy Fielding
From: Amit Goel [mailto:agoel@gmail.com]
Sent: 15 January 2012 06:41
Adobe will be donating the Flex SDK, and not the AVM/playerglobals etc.
So Adobe will continue to own the legacy on Flash and it's heart -
ActionScript/AVM.
Adobe will continue to own and control the flash players and
de aprender entonces dejarÃa de existir*
094496862 / 593-022234585
From: da...@davidarno.org
To: flex-dev@incubator.apache.org
Subject: RE: Flex incubation on Apache as Opensource
Date: Sun, 15 Jan 2012 16:01:47 +
From: Amit Goel [mailto:agoel@gmail.com]
Sent: 15 January 2012
On Sun, Jan 15, 2012 at 10:01 AM, David Arno da...@davidarno.org wrote:
Whilst Adobe will own the specification of ActionScript 3, we will own the
mxmlc and falcon compilers. We therefore get to choose what changes we make
to the language that Flex is written in. If our changes require us to
Flex 3 to Flex 4 was a small change compared with what many of us are planning
for Apache Flex: an interface, composition DI-based framework written in
AS3++ targeting JavaScript and HTML5 no less.
Davids comment made me want to hear more! What will people be working on as the
project
Also, every byte matters. You say who gives a shit about a 250 extra
bytes
in a SWF?!. I say this guy and many others. Many people are pushing for a
smaller lighter framework, not a bigger one.
I hear what you're saying, Jon, but honestly, the framework is not going to
get any smaller by
Whilst Adobe will own the specification of ActionScript 3, we will own
the mxmlc and falcon compilers. We therefore get to choose what
changes we make to the language that Flex is written in. If our
changes require us to rename the language to ApacheScript or some such,
then so be it.
Just
I think it should be clarified that a class or function with what we would
determine is a high number of lines of code does not mean that its an
indicator of crap code. If you go by line numbers then anyone who places
the opening brace on the next line will have at least 25% more lines than
8000 lines of code isn't any better than 16000 when the class drives every
single component that is put on screen. Alex said it best when he said
something along the lines of it being like trying to run fast with really
heavy shoes. I've never written a class over 500 lines of code and felt
good
I think the discussion is going on a bit of a tangent - maybe worth
renaming the topic if you want to continue it?
- Peter
I beg pardon to disagree David Arno on:
who gives a shit about a 250 extra bytes in a SWF?!
I had times when I was required to produce the reason to my client whenever
my subsequent release build of Flex swf increased by 1K. So that means I
need to clarify my client that 4 interfaces have been
On Sun, Jan 15, 2012 at 12:15 PM, David Arno da...@davidarno.org wrote:
In what way isn't what I said 100% true? Who other than Apache Flex
committers will get to choose what the future of the Flex language is?
We have control of the SDK, not the language. The language as part of the
AVM is
Subject: Re: Flex incubation on Apache as Opensource
To: flex-dev@incubator.apache.org
On Sun, Jan 15, 2012 at 12:15 PM, David Arno da...@davidarno.org wrote:
In what way isn't what I said 100% true? Who other than Apache Flex
committers will get to choose what the future of the Flex language
On Sun, Jan 15, 2012 at 1:17 PM, FRANKLIN GARZON fgarzo...@hotmail.comwrote:
I suggest, keep AVM in Adobe until Apache delivery their first version, so
we can see the potential of Flex community and contributors to build
ApacheFlex.So me question is: who has the ability to enable more OS for
To: flex-dev@incubator.apache.org
Subject: Re: Flex incubation on Apache as Opensource
I think it should be clarified that a class or function with what we
would determine is a high number of lines of code does not mean
that its an indicator of crap code.
I disagree. From experience
From: Jonathan Campos [mailto:jonbcam...@gmail.com]
Sent: 15 January 2012 19:11
We have control of the SDK, not the language.
The language as part of the AVM is still controlled by Adobe.
You are mistaken Jonathan. The AVM runs byte code, not AS3. The compiler
(which is part of the SDK and
On 1/15/2012 2:37 PM, David Arno wrote:
To: flex-dev@incubator.apache.org
Subject: Re: Flex incubation on Apache as Opensource
I think it should be clarified that a class or function with what we
would determine is a high number of lines of code does not mean
that its an indicator of crap code
When it comes to overly large classes there are a few issues:
1. overall swf file size bloat
2. performance
3. complexity when extending/modifying functionality
For me, the first point about swf file size is the least important. That
would be a great side effect if we could get the total size
On Sun, Jan 15, 2012 at 1:47 PM, David Arno da...@davidarno.org wrote:
The AVM imposes limitations on
what changes we can make to the source language (there'll be no method
overloading for example without some nasty bodges), but we can still make
significant changes.
I was simplifying my
From: Jonathan Campos [mailto:jonbcam...@gmail.com]
Sent: 15 January 2012 20:14
I was simplifying my explanation due to being mobile.
While you are correct about the implementation, that I am
not arguing, in the highlighted text I am highlighting the point
of my contention - that it
From: Jeffry Houser [mailto:jef...@dot-com-it.com]
Sent: 15 January 2012 19:54
I'm curious as to what your suggestions would be simplifying something
like this?
[Or ignoring my commercial component, the Flex List class]
I'd prefer not to comment on your commercial creations Jeffry, but
Tink, Jeffry,
Maybe I've got confused, but I was describing spark.components.List, which I
assume is a spark component. This class might be less monolithic than the
halo version, but it is ridiculous to claim it implements composition.
Take for example scrolling. In true composition, there
-it.com]
Sent: Sunday, January 15, 2012 3:55 PM
To: flex-dev@incubator.apache.org
Subject: Re: Overly large classes (was Flex incubation on Apache as Opensource)
On 1/15/2012 4:01 PM, David Arno wrote:
I'll
comment on List.
The class does many things: it's a container; it displays the contents
With all due respect to community, it makes me skeptic about what actually
Adobe is donating to Apache, and what/where Apache community is heading
with it. Correct me if I am wrong:
Adobe will be donating the Flex SDK, and not the AVM/playerglobals etc. So
Adobe will continue to own the legacy on
On 1/14/12 10:41 PM, Amit Goel agoel@gmail.com wrote:
Adobe will be donating the Flex SDK, and not the AVM/playerglobals etc. So
Adobe will continue to own the legacy on Flash and it's heart -
ActionScript/AVM. I am just thinking past sometime around the period of
Flex3, if this same
Yea, so Adobe legal is finishing up review before we receive SDK code and
then the sky (or AVM) is the limit, at least until the community visualizes
and realizes new capabilities for the SDK, such as the cross compiling to
JavaScript that have already been discussed once the FalconJS bits are
Alex,
Sure spark didn't leverage anything on that, what I mean here is an example
of what could be think of with just having a lame SDK on community's hand,
when other dependencies are owned by Adobe. And by that 'interface'
example, I was citing an example of same limitation community is having,
38 matches
Mail list logo