>> i think you miss the distinction between a language and its libraries. >> >> From my understanding the core language will provide most features >> that are available from each of the supported targets, but if you want >> to make use of specific parts of the target platform then you will >> need to use its libraries. > > > Features such as E4X and regex are part of the core ECMA language, and > are not part of the Flash's API-s or HTML API-s. > > My question is: will those be missing from haXe or not? And if not, how > can haXe be compatible with Flash 6/7/8 when these won't work there (or > will work very very slow, emulated with bytecodes).
As for E4X, when added to haXe it will be available to Flash 6/7/8 and Javascript as well by generating corresponding W3C XML accesses (if I remember correctly XMLNode acesses where faster in AS3 Alpha than using E4X...). For Regexp, yes in haXe 1.0 there will be Regexp and for Flash 6/7/8 of course a "pure haXe" implementation will be used, which will be slower than JS or AS3 API. Again, if you need more speed what you have to do is to target Player 8.5, but that doesn't mean you can't use Regexp at all. They just come with an additional cost on Flash 6/7/8, but it's already better than NO regexp support in AS2. > The time saved on having the same syntax for DHTML/Server/Flash might be > easily be lost by the lack of the productivity features specific to each > language. A language is not just syntax, it's also architecture and a type system. For example you will be able to do some kind of remoting by sending Classes (not just anonymous objects) between the client and the server. There is specific API for each platform and a standard crossplaform API. You can add API with implementations for the platforms you want. I don't know why you conclude that there will be a "lack of productivity features". Don't assume that haXe is a common denominator between all the platforms. >> And another problem is that I end up duplicating a lot of concepts and >> code that represent data and business processes (which generally have >> little dependencies on target specific libraries). >> Sure some of this can be automated, but I really like the idea of >> being able to create my value objects once, in one language. Same with >> business processes and other application logic. > > > AS3 is 100% ECMA 4 compliant (portable profile), JS itself is the base > of the ECMA spec. And there are several existing JS engines that work on > the server side. >From http://labs.macromedia.com/wiki/index.php/ActionScript_3:overview "AS3 is based on ECMAScript". haXe is based on ECMAScript as well. It provides additional features such as a Flexible type system, enums, iterators, and porting your code from AS2 to haXe is not more difficult than porting from AS2 to AS3 for example. And of course, the haXe execution model IS ECMAScript since it runs on Flash and JS VM. >> personally i think its a great idea. Its not for everyone of course >> and you are right in that there is a certain barrier to using some >> aspects of it as its not yet likely to be found as part of some cheap >> hosting deal, but for those of us who have control of our deployment >> servers it offers a great opportunity. > > > I also think it's a great idea, but the issue isn't in the idea, but > implementation: you may try to bring this idea closer to ECMA compliance > to make it more useful for the rest of us who don't want to give up on > the world to take benefit of haXe :) You don't give up anything since you can compile to SWF and JS :) Maybe thinking as haXe as a good tradeoff between Java and AS3 might make you feel better ? Although it's a bit more than that. Nicolas _______________________________________________ [email protected] To change your subscription options or search the archive: http://chattyfig.figleaf.com/mailman/listinfo/flashcoders Brought to you by Fig Leaf Software Premier Authorized Adobe Consulting and Training http://www.figleaf.com http://training.figleaf.com
