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 <labri...@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
