Re: Starting with the Whiteboard Code

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 tha

RE: Starting with the Whiteboard Code

l 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 te

Re: Starting with the Whiteboard Code

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 coll and they want that o

Re: Starting with the Whiteboard Code

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

RE: Starting with the Whiteboard Code

>>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

Re: Starting with the Whiteboard Code

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

RE: Starting with the Whiteboard Code

>>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

Re: Starting with the Whiteboard Code

On 2/8/12 6:39 AM, "Michael A. Labriola" 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, i

Re: Starting with the Whiteboard Code

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

RE: Starting with the Whiteboard Code

>>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 >

Re: Starting with the Whiteboard Code

On 2/7/12 8:51 AM, "Michael A. Labriola" 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 >>> lea

Re: Starting with the Whiteboard Code

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,

RE: Starting with the Whiteboard Code

>>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 tha

Re: Starting with the Whiteboard Code

On 2/7/12 6:45 AM, "Michael A. Labriola" 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 > optimizi

Re: Starting with the Whiteboard Code

> In > my company we keep using Flex 3, we didn't even switch to 4, cause it > isn't really worth the effort (IMHO). Oops. It was worth it. Ariel Jakobovits ajako...@adobe.com 650-350-0282 On Feb 7, 2012, at 5:23 AM, Piotr Kawiak wrote: > I totally agree with Alex. I am working in a large comp

RE: Starting with the Whiteboard Code

>>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

Re: Starting with the Whiteboard Code

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 rel

Re: Starting with the Whiteboard Code

If that's (or will be) a vote, +1 for Alex's proposal! About newbies and getting up to speed, I don't think that will be even comparable to learning (Java) Spring or Hibernate, and with a good instructor/training, it's not that difficult either. I'm all for more configuration on the minus side if

Re: Starting with the Whiteboard Code

I totally agree with Alex. I am working in a large company on enterprise scale project with Flex GUI and I'd love 'new' Flex to be backwards compatible, but this sure looks like an enormous effort. In my company we keep using Flex 3, we didn't even switch to 4, cause it isn't really worth the effor

Re: Starting with the Whiteboard Code

On 2/6/12 8:51 PM, "Justin Mclean" 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

Re: Starting with the Whiteboard Code

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:

Re: Starting with the Whiteboard Code

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 pa

Re: Starting with the Whiteboard Code

On 2/6/12 6:22 PM, "Frédéric Thomas" 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

Re: Starting with the Whiteboard Code

s, 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 w

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

Re: Starting with the Whiteboard Code

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

On 2/6/12 1 :03PM, "Martin Heidegger" 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 test

Re: Starting with the Whiteboard Code

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

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" wrote: >>Well, we think of them as unit tests because, unfortunately, our units >>are very large. :-) > >Ah yes, just redefine unit and

RE: Starting with the Whiteboard Code

>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

Re: Starting with the Whiteboard Code

On 2/5/12 9:05 AM, "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 > S

Re: Starting with the Whiteboard Code

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).

Re: Starting with the Whiteboard Code

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

Re: Starting with the Whiteboard Code

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 tes

Re: Starting with the Whiteboard Code

On 2/4/12 6:00 PM, "Martin Heidegger" 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

Re: Starting with the Whiteboard Code

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 wo

Re: Starting with the Whiteboard Code

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.