You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@flex.apache.org by Dave Fisher <da...@comcast.net> on 2012/02/05 02:46:08 UTC
Starting with the Whiteboard Code
Everyone is waiting for JIRA and SVN. Is that completely necessary?
SVN without the history is already available in the whiteboard. Certainly the project can start work, if changes are made to svn then it will be easy to take the diffs.
The build instructions[1] can be used to create instructions for the website. Build scripts can be written and shared.
Individuals can save patches to non-contributed components in their whiteboard until the components are donated or alternatives developed.
Just some thoughts. Around Apache there is a JFDI attitude.
Regards,
Dave
[1] https://svn.apache.org/repos/asf/incubator/flex/whiteboard/frameworks/README.txt
Re: Starting with the Whiteboard Code
Posted by Martin Heidegger <mh...@leichtgewicht.at>.
On 07/02/2012 09:35, Michael A. Labriola wrote:
> Unfortunately, with a few exceptions, unit tests *cannot* be written
> for the Flex framework. It isn't something that can be started.
Actually those "few exceptions" are quite many to me:
<https://svn.apache.org/repos/asf/incubator/flex/whiteboard/frameworks/projects/framework/src/mx/binding/>mx.binding.*
mx.utils.*
mx.collections.*
mx.events.*
mx.formatters.*
mx.geom.*
mx.graphics.*
mx.logging.*
mx.resources.*
mx.validators.*
mx.messaging.*
...
And yes: some of those classes do have "singletons" which means that the
unit tests will be dirty a little. But never-the-less unit tests can be
written for what looks like a quite big part of the project.
> Unit tests by definition involve the writing of a test for a single
> object isolated from all other objects, not dependent upon global
> state, that also means they can't be dependent upon things like the
> frame rate and enter frame events. Looking at something like
> UIComponent, it references singletons and static classes (global
> state). It is coupled tightly with dozens of other objects. It relies
> upon the LayoutManager, which relies upon the frames, to function.
Any system has at some point a static value. Java has it
Thread.currentThread(), PHP has global constants, etc. If we could pull
it of to create a unit test that encapsulates a component.
Take this part of the framework:
mx_internal static function get
embeddedFontRegistry():IEmbeddedFontRegistry {
if (!_embeddedFontRegistry && !noEmbeddedFonts) {
try {
_embeddedFontRegistry = IEmbeddedFontRegistry(
Singleton.getInstance("mx.core::IEmbeddedFontRegistry"));
} catch (e:Error) {
noEmbeddedFonts = true;
}
}
return _embeddedFontRegistry;
}
If we were to create a unit test environment that compiles against a
UIComponent with a different set of code like:
mx_internal static function get
embeddedFontRegistry():IEmbeddedFontRegistry {
throw new RequiresFontRegistryError();
}
then if some part of the UIComponent that is being tested that relies on
the font-registry would notify the test unit framework: "hey this
component needs to be tested with a font registry". The unit-test writer
now needs to Create two different subsets of his unit test: One in case
the font-registry is given and one in case it isn't. Once he
distinguished both tests the unit test framework has to run in both
environments:
mx_internal static function get
embeddedFontRegistry():IEmbeddedFontRegistry {
return _embeddedFontRegistry||=new TestFontRegistry;
}
and
mx_internal static function get
embeddedFontRegistry():IEmbeddedFontRegistry {
return null;
}
A definition could look like this:
class UIComponentTest implements IStateTestSuite {
public function get stateTests(): StateTestMap {
var map: StateTestMap = new StateTestMap();
map.set(ClassicTestContext, [UIComponentClassicTest]); // Classic
test for things without static references (don't need to be tested
within a context)
map.set(FontTestContext, [UIComponentFontRegistryEnabledTest,
UIComponentFontRegistryNullTest]); // FontTestContext will take two
tests and run them in a endabled and disabled state.
return map;
}
}
I know it sounds like a horrible lot to write and test, but lets face
it: It will not be simple to test code that relies on 14000 lines of a
monolith that spreads its wings. I think with a little imagination, lots
of willpower and a huge amount of coffee it might actually be testable.
yours
Martin.
Re: Starting with the Whiteboard Code
Posted by Martin Heidegger <mh...@leichtgewicht.at>.
On 10/02/2012 05:05, Michael A. Labriola wrote:
> DI in flex isn't a hard problem. It's actually pretty trivial. There are just a few places where the Flex compiler hard-codes new operators without an ability to intercept the object creation. After those lines of code are fixed (and it is a very small number for the MX stuff, more for the Spark stuff) you can make DI work easily. The next issue is then about performance impact which is what I have been trying to make more negligible as time goes on.
Isn't it just half the deal to make it basically work? The second half
would be a API to actually leverage the Dependency injection.
yours
Martin.
RE: Starting with the Whiteboard Code
Posted by "Michael A. Labriola" <la...@digitalprimates.net>.
>>I totally agree: Lets take all the momentum we have got! It sounded like you have an concept of how you would see DI in Flex Next. It would be nice if you could write the important bits and pieces down in the wiki >>so we have something to talk about!
DI in flex isn't a hard problem. It's actually pretty trivial. There are just a few places where the Flex compiler hard-codes new operators without an ability to intercept the object creation. After those lines of code are fixed (and it is a very small number for the MX stuff, more for the Spark stuff) you can make DI work easily. The next issue is then about performance impact which is what I have been trying to make more negligible as time goes on.
Mike
Notice: This transmission is intended only for the use of the individual or entity to which it is addressed and may contain information that is privileged or confidential. Any dissemination, distribution or copying of this transmission by anyone other than the intended recipient is strictly prohibited. If you have received this transmission in error, please notify the sender immediately by e-mail or telephone and delete the original transmission. Thank you.
Re: Starting with the Whiteboard Code
Posted by Tomasz Maciąg | Fuse Collective <t....@fusecollective.com>.
W dniu 2012-02-09 19:52, Martin Heidegger pisze:
> 1) A framework that produces awesome(in other words new!) experiences:
> Great design, super interactivity. Its enough if they are published
> like minimalcomps: without CSS or anything. Just so people see Apache
> Flex is coooooll and they want that on their device.
> 2) A framework that offers seamless integration in Windows 8, Android
> and iOS.
>
> Both of these ways are sufficient as experiments to gain traction.
>
> So: I saw a lot of designers participating in the Logo contest. I
> think that is our strength: How about a UI Next design&concept contest
> (without votes). It might bring us some publicity and actually good
> ideas of where the travel should go :) Whoever wants could start
> implementing the design either in Spark or Flex Next.
>
> yours
> Martin.
I think it's a great idea. Maybe we could start another topic about
that. Designing something cool that will show possible future for flex
components could help changing the trend of people moving towards HTML/JS.
This don't necessary mean a need to design complete component but maybe
just concept/wireframe that could be used by designers for further work.
Re: Starting with the Whiteboard Code
Posted by Martin Heidegger <mh...@leichtgewicht.at>.
On 10/02/2012 03:26, Michael A. Labriola wrote:
> IMO, spark was a problem because it was forced to be evolutionary. I was involved in the beginning of those decisions. I would have preferred spark be a complete rewrite based on a new ideas as well. Unfortunately with the staffing that was being allocated, the timeline to do so was prohibitive. I fear the same thing here.
I have seen/read/participated in a more than few projects that handled
it the other way around. The problem with revolution and "lets start
with a clean slate" is that it is fun at the beginning but at a certain
point you start realizing how many things you forgot that were solve
perfectly in the old system and it takes a long time to come to the same
level again.
> Changes that make it better in a month are interesting. Changes that solve real pain points that enterprises have today with using Flex might keep them on this framework and stop them from switching away... which is what every major enterprise is weighing today for new development. A theoretical rewrite that might make things better in the future requires 2 things: hope and faith. Adobe effectively abolished both of those qualities over the last few months.
Honestly speaking: All of my clients ask me for HTML 5 and nobody for
Flex. If you want to make them stick do nothing for the next twelve
months but prepare the current code base to work on JavaScript. This way
Flex might get public traction and a good image.
However there are two other strategies that could actually work:
1) A framework that produces awesome(in other words new!) experiences:
Great design, super interactivity. Its enough if they are published like
minimalcomps: without CSS or anything. Just so people see Apache Flex is
coooooll and they want that on their device.
2) A framework that offers seamless integration in Windows 8, Android
and iOS.
Both of these ways are sufficient as experiments to gain traction.
So: I saw a lot of designers participating in the Logo contest. I think
that is our strength: How about a UI Next design&concept contest
(without votes). It might bring us some publicity and actually good
ideas of where the travel should go :) Whoever wants could start
implementing the design either in Spark or Flex Next.
> I know we don't see things the same way, but a really great framework that runs on Flash Player 1 or 2 years from today is totally useless to me. None of my clients will care or notice because they won't be using this technology. My hope is that we can make changes that make the 2 year time frame matter.
I totally agree: Lets take all the momentum we have got! It sounded like
you have an concept of how you would see DI in Flex Next. It would be
nice if you could write the important bits and pieces down in the wiki
so we have something to talk about!
yours
Martin.
RE: Starting with the Whiteboard Code
Posted by "Michael A. Labriola" <la...@digitalprimates.net>.
>>Hmm. IMHO, Spark was evolutionary which I think became its biggest ball-and-chain. And when I was working on my "carve up UIComponent"
>>prototype, it was impossible to stay in sync with the rest of the team making changes in lines of code that were moving to other files.
IMO, spark was a problem because it was forced to be evolutionary. I was involved in the beginning of those decisions. I would have preferred spark be a complete rewrite based on a new ideas as well. Unfortunately with the staffing that was being allocated, the timeline to do so was prohibitive. I fear the same thing here.
Changes that make it better in a month are interesting. Changes that solve real pain points that enterprises have today with using Flex might keep them on this framework and stop them from switching away... which is what every major enterprise is weighing today for new development. A theoretical rewrite that might make things better in the future requires 2 things: hope and faith. Adobe effectively abolished both of those qualities over the last few months.
I know we don't see things the same way, but a really great framework that runs on Flash Player 1 or 2 years from today is totally useless to me. None of my clients will care or notice because they won't be using this technology. My hope is that we can make changes that make the 2 year time frame matter.
Mike
Re: Starting with the Whiteboard Code
Posted by Martin Heidegger <mh...@leichtgewicht.at>.
On 08/02/2012 23:39, Michael A. Labriola wrote:
> I would argue its ubiquity. I don't know any advanced developer that
> is excited about HTML/JS as a language. Those of us excited about it
> are excited by its ubiquity and the capabilities of the VM, not the
> language.
Limitations are sometimes the interesting thing. The strict separation
of data and logic is nowhere as celebrated and natural as in HTML &
JavaScript. Even the representation of data is very, very natural. In
the last year even the semantic web has gained traction. That is in my
opinion a language combination that in its way is unchallenged.
> I have spent the last 8 years of my life teaching and trying to get
> companies to adopt Flex. I saw it as a revolving door where people
> came in and left. Although Adobe willfully ignored it, we already had
> a huge problem converting someone new to intermediate. In my
> experience, our retention rate was around 15% of people who started
> and we had huge problems making the senior architects and developers
> in a company want to work with this framework. That in turn made it
> difficult to ever get adoption throughout.
The biggest problem for me (and companies I was involved with) was its
quality. There was no way to start low. I rather used minimal components
because a 20kb swf just had a different impact than a 400kb swf. The
"easyness of learning" was in total a smaller problem than the "bad
result". The thinking often went like "Why should I study/use Flex if I
can write this better by myself".
> Yep, that's why I think evolutionary change is better than
> revolutionary change right now
I agree: We have here a product called flex. If you create a
revolutionary new system it shouldn't be called flex anymore, its
marketing and documentation-wise a bad idea. People who used flex before
will not be able to interact with the code ... generally not preferable.
yours
Martin.
Re: Starting with the Whiteboard Code
Posted by Alex Harui <ah...@adobe.com>.
On 2/8/12 6:39 AM, "Michael A. Labriola" <la...@digitalprimates.net>
wrote:
>>> I would argue that approachability for newbies is what has made HTML/JS so
>>> popular. >
> I would argue its ubiquity.
IMHO, approachability is the foundation for the popularity that paved the
way for ubiquity.
>
>>> Agreed, but IMHO, it has to be simple not only so it can be understood by
>>> newbies and intermediates (and me), but also so it can be shippable. Spark
>>> was a better architecture than MX, but the fact is, it took too >>long to
>>> create components in Spark.
>
> Yep, that's why I think evolutionary change is better than revolutionary
> change right now
Hmm. IMHO, Spark was evolutionary which I think became its biggest
ball-and-chain. And when I was working on my "carve up UIComponent"
prototype, it was impossible to stay in sync with the rest of the team
making changes in lines of code that were moving to other files.
--
Alex Harui
Flex SDK Team
Adobe Systems, Inc.
http://blogs.adobe.com/aharui
RE: Starting with the Whiteboard Code
Posted by "Michael A. Labriola" <la...@digitalprimates.net>.
>>I would argue that approachability for newbies is what has made HTML/JS so popular. I think we need popularity in order to get buzz that opens opportunities for new work and ensures community longevity. A >>smaller community of high-end specialists have an uphill battle to fight for mindshare. But for sure, we need to make sure you can do really advanced things as well.
I would argue its ubiquity. I don't know any advanced developer that is excited about HTML/JS as a language. Those of us excited about it are excited by its ubiquity and the capabilities of the VM, not the language.
>>To me, a newbie will quickly become intermediate-level because he/she doesn't have to learn about AOP and other advanced topics, and then will need to debug an app (with a debugger, not trace statements). >>I've yet to ship anything without having to debug into it, and I think it is important to be able to understand the application behavior. Productivity is a strong-suit of Flex, especially for intermediates.
I have spent the last 8 years of my life teaching and trying to get companies to adopt Flex. I saw it as a revolving door where people came in and left. Although Adobe willfully ignored it, we already had a huge problem converting someone new to intermediate. In my experience, our retention rate was around 15% of people who started and we had huge problems making the senior architects and developers in a company want to work with this framework. That in turn made it difficult to ever get adoption throughout.
>>Agreed, but IMHO, it has to be simple not only so it can be understood by newbies and intermediates (and me), but also so it can be shippable. Spark was a better architecture than MX, but the fact is, it took too >>long to create components in Spark.
Yep, that's why I think evolutionary change is better than revolutionary change right now
>>My goal in these discussions is not to try to kill these ideas, mainly to point out the counter-arguments and explain some history. I am all for radical change, I'm planning a full re-write as you know.
Mine too :) You have history from the Adobe engineering side. I have a lot of history from the companies that chose *not* to use it. That did one project and then dropped it. The failed projects. The developers who found it unworkable and unscalable.
>>I still believe we are working with a constrained environment and techniques you might find in Java can't be universally implemented in AS.
Agreed, but concepts don't necessarily apply to one language. Their implementation pattern might. Things need to be discussed through an understanding of ActionScript but simply ignoring those possibilities as they are foreign is silly too. Sometimes a problem has been solved well.
Mike
Notice: This transmission is intended only for the use of the individual or entity to which it is addressed and may contain information that is privileged or confidential. Any dissemination, distribution or copying of this transmission by anyone other than the intended recipient is strictly prohibited. If you have received this transmission in error, please notify the sender immediately by e-mail or telephone and delete the original transmission. Thank you.
Re: Proposal: Compile-time-data injection
Posted by Ariel Jakobovits <ar...@yahoo.com>.
> I'm not sure if the Wiki is the place for proposals.
I think it makes sense. Nice way to get thoughts from emails aggregated, and even if an idea is not implemented, there is a place to come and find it and revive it someday.
Ariel Jakobovits
Email: arieljake@yahoo.com
Phone: 650-690-2213
Fax: 650-641-0031
Cell: 650-823-8699
________________________________
From: Omar Gonzalez <om...@gmail.com>
To: "flex-dev@incubator.apache.org" <fl...@incubator.apache.org>
Sent: Tuesday, February 7, 2012 9:51 AM
Subject: Re: Proposal: Compile-time-data injection
On Tuesday, February 7, 2012, Martin Heidegger <mh...@leichtgewicht.at> wrote:
> Hello everybody,
>
> in the sense of making progress I tried to write down the feature I want
to implement in the compiler once the compiler source & tests are available.
> I am not sure if I abused the wiki for that.
>
>
https://cwiki.apache.org/confluence/display/FLEX/Compile-time-data+injection
>
> yours
> Martin.
>
I'm not sure if the Wiki is the place for proposals. If we put every thing
that everyone thinks about in the wiki as a Proposal we are going to have a
lot of wiki stuff I go through. Who keeps it updated? How de we know it's
still in progress or that someone abandoned the idea?
I'm just giving my initial thoughts, don't know what the intended purpose
of the Wiki was or how Apache projects usually handle this, maybe Bertrand
or one of the other mentors can chime in?
-omar
Re: Proposal: Compile-time-data injection
Posted by Dave Fisher <da...@comcast.net>.
On Feb 7, 2012, at 9:51 AM, Omar Gonzalez wrote:
> On Tuesday, February 7, 2012, Martin Heidegger <mh...@leichtgewicht.at> wrote:
>> Hello everybody,
>>
>> in the sense of making progress I tried to write down the feature I want
> to implement in the compiler once the compiler source & tests are available.
>> I am not sure if I abused the wiki for that.
>>
>>
> https://cwiki.apache.org/confluence/display/FLEX/Compile-time-data+injection
>>
>> yours
>> Martin.
>>
>
> I'm not sure if the Wiki is the place for proposals. If we put every thing
> that everyone thinks about in the wiki as a Proposal we are going to have a
> lot of wiki stuff I go through. Who keeps it updated? How de we know it's
> still in progress or that someone abandoned the idea?
>
> I'm just giving my initial thoughts, don't know what the intended purpose
> of the Wiki was or how Apache projects usually handle this, maybe Bertrand
> or one of the other mentors can chime in?
Mentor reply: This use of the wiki is completely proper.
Regards,
Dave
>
> -omar
Re: Proposal: Compile-time-data injection
Posted by Martin Heidegger <mh...@leichtgewicht.at>.
On 08/02/2012 02:51, Omar Gonzalez wrote:
> I'm not sure if the Wiki is the place for proposals. If we put every
> thing that everyone thinks about in the wiki as a Proposal we are
> going to have a lot of wiki stuff I go through. Who keeps it updated?
> How de we know it's still in progress or that someone abandoned the idea?
Common problem with all aspects of open-source work. I have no idea what
the wiki is supposed to be used for, I just know that this is Flex
related, Flex specific and that Jira doesn't offer formatting/editing. I
could post it somewhere completely different but then this "information"
would be lost once this other place is not there anymore (common problem
with links) .
I guess for a mentor we would need to write [Mentor] in the subject, right?
yours
Martin.
Re: Proposal: Compile-time-data injection
Posted by Omar Gonzalez <om...@gmail.com>.
On Tuesday, February 7, 2012, Martin Heidegger <mh...@leichtgewicht.at> wrote:
> Hello everybody,
>
> in the sense of making progress I tried to write down the feature I want
to implement in the compiler once the compiler source & tests are available.
> I am not sure if I abused the wiki for that.
>
>
https://cwiki.apache.org/confluence/display/FLEX/Compile-time-data+injection
>
> yours
> Martin.
>
I'm not sure if the Wiki is the place for proposals. If we put every thing
that everyone thinks about in the wiki as a Proposal we are going to have a
lot of wiki stuff I go through. Who keeps it updated? How de we know it's
still in progress or that someone abandoned the idea?
I'm just giving my initial thoughts, don't know what the intended purpose
of the Wiki was or how Apache projects usually handle this, maybe Bertrand
or one of the other mentors can chime in?
-omar
Re: Proposal: Compile-time-data injection
Posted by Martin Heidegger <mh...@leichtgewicht.at>.
On 08/02/2012 02:59, Michel Boudreau wrote:
> Can I ask what
> particular issue you're having?
Hello Michel,
it would be nice if you read the proposal. I expressed the "why" and a
bunch of code that does not involve properties passed in by the
compiler. I personally need it for a more comfortable logging/trace
without wasting performance.
[Fill(scope="caller.name")]
function log(..., scope:String=null) {}
But I can see other use-cases too. The compiler arguments are just a
nice side-product that could come in handy and reduce difficulties when
working with flex.
yours
Martin.
Re: Proposal: Compile-time-data injection
Posted by Michel Boudreau <mi...@gmail.com>.
I would agree, they are not the easiest to integrate. Can I ask what
particular issue you're having? I personally like to not use compile time
variables and use an external XML to load variables through Parsley, which
then injects it automatically into wherever I need it. Maybe that would be
more suitable for your purposes.
Cheers,
M
On Tue, Feb 7, 2012 at 12:50 PM, Martin Heidegger <mh...@leichtgewicht.at>wrote:
> Hello Michel,
>
> The defined properties are just a small fraction of data that is available
> at compile time and they are not particularly easy to integrate.
>
> yours
> Martin.
>
--
Michel Boudreau
"If at first you don't succeed, use a bigger hammer." - Unofficial motto of
the Royal Electrical and Mechanical Engineers
Re: Proposal: Compile-time-data injection
Posted by Martin Heidegger <mh...@leichtgewicht.at>.
Hello Michel,
The defined properties are just a small fraction of data that is
available at compile time and they are not particularly easy to integrate.
yours
Martin.
Re: Proposal: Compile-time-data injection
Posted by Michel Boudreau <mi...@gmail.com>.
Don't compiler variables do this already with compiler.define?
-compiler.define <name> <value>
> alias -define
> define a global AS3 conditional compilation definition, e.g.
> -define=CONFIG::debugging,true or -define+=CONFIG::debugging,true (to
> append to existing definitions in flex-config.xml) (advanced,
> repeatable)
I've used this quite often in my maven builds.
M
On Tue, Feb 7, 2012 at 12:35 PM, Martin Heidegger <mh...@leichtgewicht.at>wrote:
> Hello everybody,
>
> in the sense of making progress I tried to write down the feature I want
> to implement in the compiler once the compiler source & tests are available.
> I am not sure if I abused the wiki for that.
>
> https://cwiki.apache.org/**confluence/display/FLEX/**
> Compile-time-data+injection<https://cwiki.apache.org/confluence/display/FLEX/Compile-time-data+injection>
>
> yours
> Martin.
>
--
Michel Boudreau
"If at first you don't succeed, use a bigger hammer." - Unofficial motto of
the Royal Electrical and Mechanical Engineers
Proposal: Compile-time-data injection
Posted by Martin Heidegger <mh...@leichtgewicht.at>.
Hello everybody,
in the sense of making progress I tried to write down the feature I want
to implement in the compiler once the compiler source & tests are available.
I am not sure if I abused the wiki for that.
https://cwiki.apache.org/confluence/display/FLEX/Compile-time-data+injection
yours
Martin.
Re: Starting with the Whiteboard Code
Posted by Carlos Rovira <ca...@codeoscopic.com>.
Hi Michael,
I think you're completely right, and I feel the same problems as you
comment. This new way under Apache should bring us all this new things many
advanced devs are waiting while keeping what made flex great. Evolution of
composition vs inheritance, bytecode manipulation, AOP, metadata, and so
on... are things people remaining in flex are expecting to have and one of
the reason to stay and not go the HTML5/JS way...
I think we should get some consensus to get the best of all proposals. We
can't avoid in the long term the before mentioned improvements since I
think this is part of the things that would make people select flex over
some js option.
2012/2/7 Michael A. Labriola <la...@digitalprimates.net>
> >>So yeah, I'm all for some byte-code optimizations and some fudging of
> the language rules (so you really can inline a constant), but I am still
> hoping a class definition will be same everywhere so newbies have fewer
> >>things to learn to be successful with Flex.
>
> Understood but I think that's where we disagree and so be it. I think that
> it is important to newbies can pick up a language and certainly don't wish
> to exclude anyone. However, I think when you design a language or framework
> around the newbie requirement we get something else. I think we need
> advanced features that advanced developers find powerful, useful and
> interesting. Once those exist, others build upon them, distill them into
> simple to use patterns and teach each other. We end up with a strong
> community. When we target newbies from the language side, I think we end up
> with a language used by newbies and ignored by more advanced devs. I think
> we end up with a community of newbies trying to teach each other and I
> don't think that is a good long term idea.
>
> To me, whether or not the bytecode maps back to a class cleanly is a thing
> most newbies will never know. Having both a standard way to compose a class
> and a more advanced way does not preclude someone new from using the basic
> approach, it enables someone more advanced to do interesting things.
>
> One of the long standing problems I had with Flex under Adobe's
> stewardship is that it was a collection of use cases, and when you deviated
> from the use cases to do anything more you hit a road block. It's the
> reason so many comments about private versus protected, etc. exist. A
> framework, to me, needs to be as flexible as possible to let people find
> the end goal and apply it as they see fit. A product, which is what this
> was under Adobe, needs use cases and targets a specific developer to allow
> them to do a specific task.
>
> Obviously under the Apache way we can both explore these opportunities and
> see what becomes interesting, popular and supported. I only bring these
> points up as I sometimes feel there is a knee jerk reaction, this is not
> specific to you Alex, to doing things differently than they were... I think
> a few radical advances while keeping the same general usability and
> functioning of the framework could breathe a lot of new life into it.
>
> My 4 cents.
>
> Mike
>
>
>
>
> Notice: This transmission is intended only for the use of the individual
> or entity to which it is addressed and may contain information that is
> privileged or confidential. Any dissemination, distribution or copying of
> this transmission by anyone other than the intended recipient is strictly
> prohibited. If you have received this transmission in error, please notify
> the sender immediately by e-mail or telephone and delete the original
> transmission. Thank you.
>
--
Carlos Rovira
Director de Tecnología
M: +34 607 22 60 05
F: +34 912 35 57 77
CODEOSCOPIC S.A. <http://www.codeoscopic.com>
Avd. del General Perón, 32
Planta 10, Puertas P-Q
28020 Madrid
Re: Starting with the Whiteboard Code
Posted by Alex Harui <ah...@adobe.com>.
On 2/7/12 8:51 AM, "Michael A. Labriola" <la...@digitalprimates.net>
wrote:
>>> So yeah, I'm all for some byte-code optimizations and some fudging of the
>>> language rules (so you really can inline a constant), but I am still hoping
>>> a class definition will be same everywhere so newbies have fewer >>things to
>>> learn to be successful with Flex.
>
> Understood but I think that's where we disagree and so be it. I think that it
> is important to newbies can pick up a language and certainly don't wish to
> exclude anyone. However, I think when you design a language or framework
> around the newbie requirement we get something else. I think we need advanced
> features that advanced developers find powerful, useful and interesting.
I would argue that approachability for newbies is what has made HTML/JS so
popular. I think we need popularity in order to get buzz that opens
opportunities for new work and ensures community longevity. A smaller
community of high-end specialists have an uphill battle to fight for
mindshare. But for sure, we need to make sure you can do really advanced
things as well.
> When we target
> newbies from the language side, I think we end up with a language used by
> newbies and ignored by more advanced devs.
ActionScript is designed to be a language used by newbies. I'm not sure how
much we want to become more strict like Java unless it provides significant
performance gains.
>
> To me, whether or not the bytecode maps back to a class cleanly is a thing
> most newbies will never know.
To me, a newbie will quickly become intermediate-level because he/she
doesn't have to learn about AOP and other advanced topics, and then will
need to debug an app (with a debugger, not trace statements). I've yet to
ship anything without having to debug into it, and I think it is important
to be able to understand the application behavior. Productivity is a
strong-suit of Flex, especially for intermediates.
>
> A framework, to me, needs
> to be as flexible as possible to let people find the end goal and apply it as
> they see fit.
Agreed, but IMHO, it has to be simple not only so it can be understood by
newbies and intermediates (and me), but also so it can be shippable. Spark
was a better architecture than MX, but the fact is, it took too long to
create components in Spark.
>
> I only bring these points up
> as I sometimes feel there is a knee jerk reaction, this is not specific to you
> Alex, to doing things differently than they were... I think a few radical
> advances while keeping the same general usability and functioning of the
> framework could breathe a lot of new life into it.
My goal in these discussions is not to try to kill these ideas, mainly to
point out the counter-arguments and explain some history. I am all for
radical change, I'm planning a full re-write as you know.
I still believe we are working with a constrained environment and techniques
you might find in Java can't be universally implemented in AS. And, that
approachability is important, but we absolutely have to make it possible to
polish advanced applications by allowing for optimization by experts. My
prediction is that we will end up with a composition-based framework that
doesn't use AOP in the components and infrastructure commonly used by
newbies and intermediates, but makes it possible for advanced users to use
it on the edges and in their code. I would argue the same for concurrency
if we ever get to leverage it.
But only time will tell...
--
Alex Harui
Flex SDK Team
Adobe Systems, Inc.
http://blogs.adobe.com/aharui
RE: Starting with the Whiteboard Code
Posted by "Michael A. Labriola" <la...@digitalprimates.net>.
>>So yeah, I'm all for some byte-code optimizations and some fudging of the language rules (so you really can inline a constant), but I am still hoping a class definition will be same everywhere so newbies have fewer >>things to learn to be successful with Flex.
Understood but I think that's where we disagree and so be it. I think that it is important to newbies can pick up a language and certainly don't wish to exclude anyone. However, I think when you design a language or framework around the newbie requirement we get something else. I think we need advanced features that advanced developers find powerful, useful and interesting. Once those exist, others build upon them, distill them into simple to use patterns and teach each other. We end up with a strong community. When we target newbies from the language side, I think we end up with a language used by newbies and ignored by more advanced devs. I think we end up with a community of newbies trying to teach each other and I don't think that is a good long term idea.
To me, whether or not the bytecode maps back to a class cleanly is a thing most newbies will never know. Having both a standard way to compose a class and a more advanced way does not preclude someone new from using the basic approach, it enables someone more advanced to do interesting things.
One of the long standing problems I had with Flex under Adobe's stewardship is that it was a collection of use cases, and when you deviated from the use cases to do anything more you hit a road block. It's the reason so many comments about private versus protected, etc. exist. A framework, to me, needs to be as flexible as possible to let people find the end goal and apply it as they see fit. A product, which is what this was under Adobe, needs use cases and targets a specific developer to allow them to do a specific task.
Obviously under the Apache way we can both explore these opportunities and see what becomes interesting, popular and supported. I only bring these points up as I sometimes feel there is a knee jerk reaction, this is not specific to you Alex, to doing things differently than they were... I think a few radical advances while keeping the same general usability and functioning of the framework could breathe a lot of new life into it.
My 4 cents.
Mike
Notice: This transmission is intended only for the use of the individual or entity to which it is addressed and may contain information that is privileged or confidential. Any dissemination, distribution or copying of this transmission by anyone other than the intended recipient is strictly prohibited. If you have received this transmission in error, please notify the sender immediately by e-mail or telephone and delete the original transmission. Thank you.
Re: Starting with the Whiteboard Code
Posted by Alex Harui <ah...@adobe.com>.
On 2/7/12 6:45 AM, "Michael A. Labriola" <la...@digitalprimates.net>
wrote:
>
> I understand your position, however, I really think that some of the byte code
> approaches could get us very maintainable code and speed of execution. That's
> why I am so interested in this approach. Honestly, with a really good
> optimizing compiler it is difficult to take final byte code and trace it back
> to original source as well.
It will come down to what you get for that optimization that breaks the
mapping from byte code to source. Even if it is 10% for 1% of the cases,
then I would say it isn't worth it, or at least, a non-default option, and
the framework needs to work well for the other 99% of the cases, and I am
saying I would drop 100% backward compatibility rather than break that
mapping.
The MSVC compiler can do inlining and tail call optimizations that greatly
speed up the kind of things I think the 99% is going to need without making
it totally impossible to map backward from bytecode to source.
So yeah, I'm all for some byte-code optimizations and some fudging of the
language rules (so you really can inline a constant), but I am still hoping
a class definition will be same everywhere so newbies have fewer things to
learn to be successful with Flex.
--
Alex Harui
Flex SDK Team
Adobe Systems, Inc.
http://blogs.adobe.com/aharui
RE: Starting with the Whiteboard Code
Posted by "Michael A. Labriola" <la...@digitalprimates.net>.
>>Under the looser Wikipedia definition, the current mustella test suite (note that I have not called it a unit testing framework on this mailing list) has tests for the major classes in the framework. When you finally see >>the code, there is a class called UnitTester that contains a set of tests. Mike will probably rename that class shortly after I check it in :-)
Just to clarify, I think mustella is a good thing. I think having these tests is absolutely critical and they do a good job. I want to see those continue to exist and evolve, however, to me unit tests are also important. Not only do they allow precise understanding of where code breaks after a change, they actually serve as a guide to me as to when we have code that is way too coupled. Also, imagine how nice it might be if people could propose a patch with a unit test that shows it works. The mustella tests actually need to restart the VM a number of times in the source of their running because of state. I am not saying that makes them bad, I am just saying it doesn't make them unit tests. To me they are somewhere between big integration tests and functional tests.
>>The SDK code is the way it is because it started out in AS2 in a VM where object creation was very expensive. We got our performance improvements by having large monolithic classes. When we ported to AS3, we >>could not be sure of its performance characteristics, so we did a straight port and kept those large classes. AS3 was much faster, but as I said, in my attempt to do a major refactoring, there was a performance hit for >>small apps, and with mobile being a important target, we opted not to pursue a refactoring.
I think all of that is fair and I also think we just need to figure out where we can and cannot compromise.
>>I'm not a big fan of doing things to the byte code such that you lose the ability to map the code back to the source code, but I still believe we can make the right trade-offs and get a better framework. I am still >>planning on giving up on strict backward compatibility and starting over.
I understand your position, however, I really think that some of the byte code approaches could get us very maintainable code and speed of execution. That's why I am so interested in this approach. Honestly, with a really good optimizing compiler it is difficult to take final byte code and trace it back to original source as well. When we see falcon someday, my goal would be to slowly add those type of optimizations into it in either case as I think there are huge gains to be made at that level. So, since I am all for screwing up your source to byte code relationship in the name of those optimizations, I am just asking that we consider screwing it up even earlier in the name of maintainable code and efficiency. Frankly, I think we could keep most backward compatibility in this model and still achieve our goals.
Notice: This transmission is intended only for the use of the individual or entity to which it is addressed and may contain information that is privileged or confidential. Any dissemination, distribution or copying of this transmission by anyone other than the intended recipient is strictly prohibited. If you have received this transmission in error, please notify the sender immediately by e-mail or telephone and delete the original transmission. Thank you.
Re: Starting with the Whiteboard Code
Posted by Martin Heidegger <mh...@leichtgewicht.at>.
> I was working on something like an AspectJ implementation ...
Compile-time-AOP has the obvious problem that you can not load an
additional library at runtime into a container. That is one of the main
reason for the popularity of spring in java - it offered reasonably fast
AOP at runtime that allowed loading of jars at a significantly reduced
compile time. Of course Java is a different game than AS3: A typical
Java - serverside - application has a runtime that is a little longer
than the common swf.
What about the option that the compiler created something like:
var inst: MyClass = new (ASPECT_CACHE['com.mycompany.MyClass'] ||=
ASPECT_STRATEGY.getConstructor('com.mycompany.MyClass')) ();
In other words it had to replace all class references with this code.
This would bloat the swf size but I assume it is reasonably fast, faster
than for example replacing it with a function. Another thing on
performance is the current problem of dynamic proxy creation. If Proxies
need to be created then the whole startup will be delayed. It could be
pretty fast, admittingly not as fast as using directly baked proxies but
still: Pretty fast.
If the "Aspect Strategy" would be implemented with special statements to
pre-bake the custom classes that it modifies then it almost wouldn't
waste any startup time.
This way one could load regular swfs and they would still be treated
under the same aspect system that could be loaded at runtime. This would
also allow the system to be setup with an xml that is loaded for
example. I happened to find that pretty useful on various occasions.
>> If I'm not wrong, you did some deep experiments in DI and AOP, what can you say about performences ? did you do measurements ? if yes, how ?
@Michael What about dependency injection. Does it need to be tightly coupled to AOP? The difference between DI and AOP is to me that AOP will be used at code that is not prepared for AOP while DI has to be marked for it.
I hope I am expressing myself right here:
AOP:
1) Intercept the creation of *any* class
2) Wrap the class with more functionality
3) Spit it out.
DI:
1) Intercept the creation of a *specific* class
2) Pre-fill various properties
3) Spit it out.
The difference being that you don't need a custom constructor logic for property injection (most common type).
So: Do you think it would be possible to have a "less-complex" solution that would just implement certain parts of DI?
yours
Martin.
RE: Starting with the Whiteboard Code
Posted by "Michael A. Labriola" <la...@digitalprimates.net>.
>>If I'm not wrong, you did some deep experiments in DI and AOP, what can you say about performences ? did you do measurements ? if yes, how ?
Because of the VM limitations, the type of AOP I was most interested in was compile time. I was working on something like an AspectJ implementation. Some of the first features were things like compile-time mixins and interface implementation mapping, so that you can indicate an object needs to implement an interface, provide a mapping to a mixin and have the compiler mix those classes together .
This meant that we can still have small and a relatively decoupled programming model, and yet let as avoid some of the costs that Alex was referring to. Effectively, at compile time, there are no extra function closures, function calls or delegations for the VM to deal with.
My experiments with DI are very subjective. I was willing to pay the extra cost for instantiating an object as required to do DI. I very much care about testing objects and replacing their implementations. My feelings on this are pretty simple, yes, this introduces overhead, but it makes so many things faster to develop, maintain, test and extend than before that I am willing to take a performance degradation in some areas. However, this also means I don't have to take everything.
Meaning that, if this is done properly, I could decide not to inject a heavy weight style manager. I could inject different implementations of some key features that are lighter-weight or perhaps no implementation at all. I could let people develop different binding implementations which work differently for different requirements. That flexibility, in my mind, means the Flex framework becomes a pay-as-you-go model. If you need all of the features in a large enterprise app, you can have them. However, I do not have to have all of the heaviest implementations in a mobile application.
To me, the net result would be a reduction in size and an increase in speed.
My thoughts,
Mike
-----Message d'origine-----
From: Michael A. Labriola
Sent: Tuesday, February 07, 2012 1:35 AM
To: flex-dev@incubator.apache.org
Subject: RE: Starting with the Whiteboard Code
>> Writing unit tests for the framework is something that could be
>>started now. The framework code is out there.
>>Are the other ones logical tests? In other words: Would they need to
>>be ported to a unit-test system?
Unfortunately, with a few exceptions, unit tests *cannot* be written for the Flex framework. It isn't something that can be started. Unit tests by definition involve the writing of a test for a single object isolated from all other objects, not dependent upon global state, that also means they can't be dependent upon things like the frame rate and enter frame events.
Looking at something like UIComponent, it references singletons and static classes (global state). It is coupled tightly with dozens of other objects.
It relies upon the LayoutManager, which relies upon the frames, to function.
There is nothing about the current state of Flex that approaches being testable in units. That's why so many of us have been arguing for refactoring for so long. Since most of our code involves extending or referencing Flex classes, and in most cases there aren't interfaces for those implementations, our code becomes un-unit-testable by association.
Mike
Notice: This transmission is intended only for the use of the individual or entity to which it is addressed and may contain information that is privileged or confidential. Any dissemination, distribution or copying of this transmission by anyone other than the intended recipient is strictly prohibited. If you have received this transmission in error, please notify the sender immediately by e-mail or telephone and delete the original transmission. Thank you.
Re: Starting with the Whiteboard Code
Posted by Justin Mclean <ju...@classsoftware.com>.
Hi,
> Nothing specific at this time. Mainly, I will be willing to break
> compatibility to achieve a significant goal, whether it is performance, DI,
> unit-testing, cross-compilation to HTML/CSS/JS, accessibility, size, etc.
I have no issue with that as long as the upgrade/conversion path is relatively easy and/or well documented. Which I'm sure it will be.
> For sure, making the porting effort too large would cause folks to not port.
> But my thoughts after the summit was that if Flex is at one extreme and
> HTML/CSS/JS is at the other and we are clearly hearing the pain of going
> from one to the other, I believe we could find a midpoint (not necessarily
> at 50%) where all of the above goals and more are achieved such that it is
> worth making a significant (although much less significant) port effort than
> going the whole distance.
The issue is here that people often see than if we have to go to some effort to convert we might as well go all out and change everything. Logically it makes no sense but I've seen it happen time and time again.My view (and others will disagree but that's fine) is that we need to initially make any changes to the SDK easy to swallow Long term I'm all for anything that makes a major improvement even if it break backwards compatibility.
> And I hope that with a composition-based framework, you can make your own trade-offs as to where the midpoint is.
Yep I'm all for that.
> This is a good opportunity to point out one of the counter arguments to my
> philosophy: these kinds of frameworks tend to require more configuration and
> make it less approachable to newbies.
Good documentation (and code examples) can help there.
It's great to see the thinking/reasoning behind in where you want to take the framework, it's something we wouldn't of seen in the old Adobe way of deciding future versions of the SDK.
Thanks,
Justin
Re: Starting with the Whiteboard Code
Posted by Alex Harui <ah...@adobe.com>.
On 2/6/12 8:51 PM, "Justin Mclean" <ju...@classsoftware.com> wrote:
> Anything in particular you thinking of breaking or is this just a general
> statement and more long term than short term thinking?
Nothing specific at this time. Mainly, I will be willing to break
compatibility to achieve a significant goal, whether it is performance, DI,
unit-testing, cross-compilation to HTML/CSS/JS, accessibility, size, etc.
For sure, making the porting effort too large would cause folks to not port.
But my thoughts after the summit was that if Flex is at one extreme and
HTML/CSS/JS is at the other and we are clearly hearing the pain of going
from one to the other, I believe we could find a midpoint (not necessarily
at 50%) where all of the above goals and more are achieved such that it is
worth making a significant (although much less significant) port effort than
going the whole distance. And I hope that with a composition-based
framework, you can make your own trade-offs as to where the midpoint is. If
you need to bake in some heavy Flex feature because your whole existing
infrastructure is based on it, you can mix that feature/behavior in, but
then you might suffer when cross-compiling or in performance.
This is a good opportunity to point out one of the counter arguments to my
philosophy: these kinds of frameworks tend to require more configuration and
make it less approachable to newbies. For example, today you add in a List
control, turn on dragEnabled and you can drag/drop. That's because List has
a hard dependency on DragManager. Once you re-package that into a behavior,
you have to configure that behavior in, otherwise turning on dragEnabled
won't do anything useful, and in some API designs, there is no dragEnabled
flag and you have to find the class/behavior to mix in out of the 1000's of
classes out there.
One of the analogies I used in the past is with screwdrivers (although
wrenches work just as well). In the current Flex SDK, we sell only one
screwdriver. It is that one with the fat handle that stores several tips.
That's it. Only one to choose from, and you don't have to look ahead to
know if the screw you need to drive is phillips, regular, star, etc. Just
grab it and go.
I do own such a screwdriver at home, but if you look through my tool
cabinet, you will also find several of those sets of screwdrivers, all lines
up with slightly different tip sizes. And I've always preferred these sets
despite the fact that I often grab the wrong one and have to put it back and
try a couple more until I find the one I need. Why? Because every once in
a while, I need to drive a screw in a tight spot or carry the tool behind my
ear (mobile apps). IOW, I'm ok with the pain because it allows
optimization. But it is less approachable. The choices can overwhelm and
we still need to make newbies successful. However, I think there are other
ways to help folks manage choices, and I think I would rather we make it
possible to finish the "last mile" of optimization better than we do now so
we can have some killer showcase apps out there that folks can actually
touch and use.
--
Alex Harui
Flex SDK Team
Adobe Systems, Inc.
http://blogs.adobe.com/aharui
Re: Starting with the Whiteboard Code
Posted by Justin Mclean <ju...@classsoftware.com>.
Hi,
> I am still planning on giving up on strict backward compatibility and starting over.
> Refactoring is hard, and trying to synchronize it with what I hope will be
> tons of changes going forward will be very difficult.
If we break backward compatibility we will need to have an upgrade path for existing applications than can be achieved with a minimal amount of work. A lot of people are not going to use the new framework if it requires too much work (and thus cost) to port exiting application to. If it becomes a large effort they may just decide to go with another technology or keep using the old SDK for as long as they can. Anything in particular you thinking of breaking or is this just a general statement and more long term than short term thinking?
Perhaps a better way forward it to take some performance hits and them try and optimise for performance. There are certainly parts of the SDK that can be improved performance wise with minor changes to the SDK.
Thanks,
Justin
Re: Starting with the Whiteboard Code
Posted by Alex Harui <ah...@adobe.com>.
On 2/6/12 6:22 PM, "Frédéric Thomas" <we...@hotmail.com> wrote:
> Michael,
>
> Thanks to clarify that point, it's very important to know that in the actual
> state, the framework is un-unit-testable (mainly for UIComponent(s) I guess,
> is that the same for the all framework ?).
>
I'm hoping Mike will quote his definition of a unit test. I suspect it is
from some standards body he told me about that I can't remember but I'm all
for shooting to meet its requirements. For sure, there is not enough
separation of concerns to allow substitution of dependencies of most of the
classes in the SDK.
Under the looser Wikipedia definition, the current mustella test suite (note
that I have not called it a unit testing framework on this mailing list) has
tests for the major classes in the framework. When you finally see the
code, there is a class called UnitTester that contains a set of tests. Mike
will probably rename that class shortly after I check it in :-)
The SDK code is the way it is because it started out in AS2 in a VM where
object creation was very expensive. We got our performance improvements by
having large monolithic classes. When we ported to AS3, we could not be
sure of its performance characteristics, so we did a straight port and kept
those large classes. AS3 was much faster, but as I said, in my attempt to
do a major refactoring, there was a performance hit for small apps, and with
mobile being a important target, we opted not to pursue a refactoring.
I'm not a big fan of doing things to the byte code such that you lose the
ability to map the code back to the source code, but I still believe we can
make the right trade-offs and get a better framework. I am still planning
on giving up on strict backward compatibility and starting over.
Refactoring is hard, and trying to synchronize it with what I hope will be
tons of changes going forward will be very difficult.
--
Alex Harui
Flex SDK Team
Adobe Systems, Inc.
http://blogs.adobe.com/aharui
Re: Starting with the Whiteboard Code
Posted by Frédéric Thomas <we...@hotmail.com>.
Michael,
Thanks to clarify that point, it's very important to know that in the actual
state, the framework is un-unit-testable (mainly for UIComponent(s) I guess,
is that the same for the all framework ?).
"It is coupled tightly with dozens of other objects"
I'm doing an experiment to loosely coupled UIComponent, I'll probably push
today on github what I already done, It's just a staring point and just a
small part of what should be done (that is to say : States, transitions,
effects, automation, styling implemented as Behaviors).
(BTW, I'm looking for interested folks willing to spend time on this
development)
Alex Harui said he succeeded chopped UIComponent into over 20 pieces but the
perfs were bad because of the intersticial cost of the calls, here are the
pieces of the conversation :
"Further back in this thread I stated that the prototype was not faster
because of 'interstitial' costs: the cost of adding an additional function
call to get to the subobject that actually does the work.
I think you have to give up on something: backward-compatibility, keeping
certain high-bandwidth 'behaviors' baked in', memory footprint, in order to
get gains.
Or do something more clever like figuring out how to do post-process
optimization of the SWF that can set up tail-call optimizations and reduce
the interstitial cost."
>>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 the function owner (but maybe that's what makes it a
>>closure)?
>Believe me, I was surprised to find this out as well. Basically, it is
>because of an inefficient implementation in the VM.
>At minimum, it has to reference two things: the pointer to the 'this'
>object
>and the pointer to the name of the method, so I'm pretty sure it has to be
>at least 8 bytes, but when I asked about it a while back, they decided it
>couldn't be less than 32 bytes (yes, bytes not bits). Apparently there is
>other stuff that needs to be tracked as well.
Personally, in the tests I did, I wasn't able to efficiently measure the
perfs, at the moment, I plug the behaviors at instanciation time but it
takes the simple to the double to instanciate, it's variable, do you know a
good way to perform efficiently these kind of tests ?
Did you already tried to loosly coupled UIComponent ?
Alex stated as well that "Interfaces, modularity and DI are all good things"
but using Interfaces is unacceptable because the performences loss :
"Also, the AVM is not like the JVM. For various reasons, language features
are not necessarily implemented as you might expect. An empty interface
takes up 250 bytes in the SWF and about 1K of memory at runtime and causes
an empty interface constructor to run at when first used. So, pairing every
class in the framework with an interface will likely degrade performance
unacceptably."
If I'm not wrong, you did some deep experiments in DI and AOP, what can you
say about performences ? did you do measurements ? if yes, how ?
I would be really interested to see what you did about that.
(And once again, sorry for my english, trying to get better).
-----Message d'origine-----
From: Michael A. Labriola
Sent: Tuesday, February 07, 2012 1:35 AM
To: flex-dev@incubator.apache.org
Subject: RE: Starting with the Whiteboard Code
>> Writing unit tests for the framework is something that could be started
>> now. The framework code is out there.
>>Are the other ones logical tests? In other words: Would they need to be
>>ported to a unit-test system?
Unfortunately, with a few exceptions, unit tests *cannot* be written for the
Flex framework. It isn't something that can be started. Unit tests by
definition involve the writing of a test for a single object isolated from
all other objects, not dependent upon global state, that also means they
can't be dependent upon things like the frame rate and enter frame events.
Looking at something like UIComponent, it references singletons and static
classes (global state). It is coupled tightly with dozens of other objects.
It relies upon the LayoutManager, which relies upon the frames, to function.
There is nothing about the current state of Flex that approaches being
testable in units. That's why so many of us have been arguing for
refactoring for so long. Since most of our code involves extending or
referencing Flex classes, and in most cases there aren't interfaces for
those implementations, our code becomes un-unit-testable by association.
Mike
Notice: This transmission is intended only for the use of the individual or
entity to which it is addressed and may contain information that is
privileged or confidential. Any dissemination, distribution or copying of
this transmission by anyone other than the intended recipient is strictly
prohibited. If you have received this transmission in error, please notify
the sender immediately by e-mail or telephone and delete the original
transmission. Thank you.
RE: Starting with the Whiteboard Code
Posted by "Michael A. Labriola" <la...@digitalprimates.net>.
>> Writing unit tests for the framework is something that could be started now. The framework code is out there.
>>Are the other ones logical tests? In other words: Would they need to be ported to a unit-test system?
Unfortunately, with a few exceptions, unit tests *cannot* be written for the Flex framework. It isn't something that can be started. Unit tests by definition involve the writing of a test for a single object isolated from all other objects, not dependent upon global state, that also means they can't be dependent upon things like the frame rate and enter frame events.
Looking at something like UIComponent, it references singletons and static classes (global state). It is coupled tightly with dozens of other objects. It relies upon the LayoutManager, which relies upon the frames, to function.
There is nothing about the current state of Flex that approaches being testable in units. That's why so many of us have been arguing for refactoring for so long. Since most of our code involves extending or referencing Flex classes, and in most cases there aren't interfaces for those implementations, our code becomes un-unit-testable by association.
Mike
Notice: This transmission is intended only for the use of the individual or entity to which it is addressed and may contain information that is privileged or confidential. Any dissemination, distribution or copying of this transmission by anyone other than the intended recipient is strictly prohibited. If you have received this transmission in error, please notify the sender immediately by e-mail or telephone and delete the original transmission. Thank you.
Re: Starting with the Whiteboard Code
Posted by Martin Heidegger <mh...@leichtgewicht.at>.
On 07/02/2012 04:52, Carol Frampton wrote:
> Many, but not all, do screen compares
Are the other ones logical tests? In other words: Would they need to be
ported to a unit-test system?
yours
Martin.
Re: Starting with the Whiteboard Code
Posted by Carol Frampton <cf...@adobe.com>.
On 2/6/12 1 :03PM, "Martin Heidegger" <mh...@leichtgewicht.at> wrote:
>On 07/02/2012 02:28, Carol Frampton wrote:
>> Writing unit tests for the framework is something that could be started
>> now. The framework code is out there.
>There are no tests to the framework? Or just no unit tests?
There are thousands of tests for the framework but they are all run within
the "mustella" framework. Many, but not all, do screen compares, which
has its set of advantages and disadvantages. Ideally they produce the
same output on Windows and Mac but that is not always the case and the
tests tend to run cleaner on Windows.
Carol
Re: Starting with the Whiteboard Code
Posted by Martin Heidegger <mh...@leichtgewicht.at>.
On 07/02/2012 02:28, Carol Frampton wrote:
> Writing unit tests for the framework is something that could be started
> now. The framework code is out there.
There are no tests to the framework? Or just no unit tests?
Re: Starting with the Whiteboard Code
Posted by Carol Frampton <cf...@adobe.com>.
Writing unit tests for the framework is something that could be started
now. The framework code is out there.
Carol
On 2/6/12 8 :02AM, "Michael A. Labriola" <la...@digitalprimates.net>
wrote:
>>Well, we think of them as unit tests because, unfortunately, our units
>>are very large. :-)
>
>Ah yes, just redefine unit and then we have unit tests. If we also
>redefine poor coupling, good startup performance, and small size to mean
>different things as well, then we are 100% done.
>
>A unit test has a meaning and I don't think redefining it is the right
>approach to solving the problem,
>Mike
>
>
>Notice: This transmission is intended only for the use of the individual
>or entity to which it is addressed and may contain information that is
>privileged or confidential. Any dissemination, distribution or copying of
>this transmission by anyone other than the intended recipient is strictly
>prohibited. If you have received this transmission in error, please
>notify the sender immediately by e-mail or telephone and delete the
>original transmission. Thank you.
RE: Starting with the Whiteboard Code
Posted by "Michael A. Labriola" <la...@digitalprimates.net>.
>Well, we think of them as unit tests because, unfortunately, our units are very large. :-)
Ah yes, just redefine unit and then we have unit tests. If we also redefine poor coupling, good startup performance, and small size to mean different things as well, then we are 100% done.
A unit test has a meaning and I don't think redefining it is the right approach to solving the problem,
Mike
Notice: This transmission is intended only for the use of the individual or entity to which it is addressed and may contain information that is privileged or confidential. Any dissemination, distribution or copying of this transmission by anyone other than the intended recipient is strictly prohibited. If you have received this transmission in error, please notify the sender immediately by e-mail or telephone and delete the original transmission. Thank you.
Re: Starting with the Whiteboard Code
Posted by Martin Heidegger <mh...@leichtgewicht.at>.
Nick,
that sounds quirky and interesting, cant wait to peek onto those tests
yours
Martin
On 06/02/2012 02:05, Nicholas Kwiatkowski wrote:
> Martin,
>
> There are no unit tests for each module. They do not exist. Adobe has
> typically only done functional testing (using their custom testing suite).
> One of the early goals of at least some of the PPMC members is to make the
> SDK unit-testable.
>
> -Nick
>
Re: Starting with the Whiteboard Code
Posted by Alex Harui <ah...@adobe.com>.
On 2/5/12 9:05 AM, "Nicholas Kwiatkowski" <ni...@spoon.as> wrote:
> Martin,
>
> There are no unit tests for each module. They do not exist. Adobe has
> typically only done functional testing (using their custom testing suite).
> One of the early goals of at least some of the PPMC members is to make the
> SDK unit-testable.
Well, we think of them as unit tests because, unfortunately, our units are
very large. :-)
--
Alex Harui
Flex SDK Team
Adobe Systems, Inc.
http://blogs.adobe.com/aharui
Re: Starting with the Whiteboard Code
Posted by Nicholas Kwiatkowski <ni...@spoon.as>.
Martin,
There are no unit tests for each module. They do not exist. Adobe has
typically only done functional testing (using their custom testing suite).
One of the early goals of at least some of the PPMC members is to make the
SDK unit-testable.
-Nick
On Sun, Feb 5, 2012 at 10:02 AM, Martin Heidegger <mh...@leichtgewicht.at>wrote:
> Hello Alex,
>
> Thank you for the clarification. I sure sounds like a lot of good reasons
> as to why this might take a while.
> Your efforts are awesome!
>
> However: I have another thought popping up: Do you think once you arrived
> at the unit tests it would take a lot of effort to publish the unit tests
> by the module? Listening to your elaboration the whole effort could mean
> more than a month of work from your side. The parts of the framework to
> which unit tests are available could be worked on before everything is
> done. Well, that's just a thought I don't mean to be pushy.
>
> yours
> Martin
>
> Side note to myself: Avoid copyrighted material for test cases. ;)
>
>
> On 05/02/2012 22:03, Alex Harui wrote:
>
>> Every file Adobe donates has to be scrubbed. Carol and I are fully booked
>> getting SVN history and JIRA. Next is the compiler for which we keep
>> hitting legal issues. After that is the test suite which we know needs
>> every font file replaced or re-scripted, and tons of images reviewed
>> manually for copyright infringement. For example, an image item renderer
>> test used Adobe product logos and each of those logos needs to be replaced
>> and the baseline comparision images re-made. It is just going to take a
>> while.
>>
>
>
Re: Starting with the Whiteboard Code
Posted by Martin Heidegger <mh...@leichtgewicht.at>.
Hello Alex,
Thank you for the clarification. I sure sounds like a lot of good
reasons as to why this might take a while.
Your efforts are awesome!
However: I have another thought popping up: Do you think once you
arrived at the unit tests it would take a lot of effort to publish the
unit tests by the module? Listening to your elaboration the whole effort
could mean more than a month of work from your side. The parts of the
framework to which unit tests are available could be worked on before
everything is done. Well, that's just a thought I don't mean to be pushy.
yours
Martin
Side note to myself: Avoid copyrighted material for test cases. ;)
On 05/02/2012 22:03, Alex Harui wrote:
> Every file Adobe donates has to be scrubbed. Carol and I are fully booked
> getting SVN history and JIRA. Next is the compiler for which we keep
> hitting legal issues. After that is the test suite which we know needs
> every font file replaced or re-scripted, and tons of images reviewed
> manually for copyright infringement. For example, an image item renderer
> test used Adobe product logos and each of those logos needs to be replaced
> and the baseline comparision images re-made. It is just going to take a
> while.
Re: Starting with the Whiteboard Code
Posted by Alex Harui <ah...@adobe.com>.
On 2/4/12 6:00 PM, "Martin Heidegger" <mh...@leichtgewicht.at> wrote:
> I am wondering what kept the adobe team from publishing the unit tests
> with the rest of
> the code to the whiteboard.
Every file Adobe donates has to be scrubbed. Carol and I are fully booked
getting SVN history and JIRA. Next is the compiler for which we keep
hitting legal issues. After that is the test suite which we know needs
every font file replaced or re-scripted, and tons of images reviewed
manually for copyright infringement. For example, an image item renderer
test used Adobe product logos and each of those logos needs to be replaced
and the baseline comparision images re-made. It is just going to take a
while.
--
Alex Harui
Flex SDK Team
Adobe Systems, Inc.
http://blogs.adobe.com/aharui
Re: Starting with the Whiteboard Code
Posted by Martin Heidegger <mh...@leichtgewicht.at>.
On 05/02/2012 10:53, Omar Gonzalez wrote:
> Personally what I've been waiting for is the bug list and the test suite.
> Hard to know if we've broken something without the tests and knowing how to
> run them. I agree some things can be done, but I don't see how we could
> release them confidently.
I am wondering what kept the adobe team from publishing the unit tests
with the rest of
the code to the whiteboard.
yours
Martin.
Re: Starting with the Whiteboard Code
Posted by Omar Gonzalez <om...@gmail.com>.
Personally what I've been waiting for is the bug list and the test suite.
Hard to know if we've broken something without the tests and knowing how to
run them. I agree some things can be done, but I don't see how we could
release them confidently.