>From all tests I made so far, declaring all functions with numbers >instead of with names should speed up things.
Yes it does for sure, I've done it, and measured it, and it is many times faster. > Earlier you mentioned an optimization technique for method > overloading. I don't think doing something like... > > myMethod_1( id:String ); > myMethod_2(); That will still work if you store everything in tables (arrays). You can also store the metadata separately or within the app (names, mangled names etc), and then enable reflection. That can happen invisible to the user like in the case of an imported 'dll' swf, or explicity (we implemented the reflection framework from .net for that). As for all the conversation about 'official' languages vs grassroots ones, it reminds me of a quote from some dead linguist - "A language is a dialect with an army and a navy". In this case though the 'army and navy' is probably a good suite of tools, IDE and debugger ; ). Personally I think the new JS specs aren't that great. It is trying to be more scalable by adding a lot of Java type features, but it is still dynamic, so it will never be scalable. AS2 suffers from the same problem, as I'm sure AS3 does. At Aptana we worked for months on a good Javascript IDE, and got quite far imo (intellisense that was mostly complete and correct, scriptdoc, debugging etc). But then to get to level 2, where you would trust it to do a big refactor on your code (something you do all the time in Java/C#), there is no way. The language allows too many crazy things to happen to be able to trust automation to that level. JS is a great language for quick and dirty projects, but like all dynamic languages it scales poorly and is difficult to tool. So anyone working on getting past that problem should be thanked imo. The issue with starting a new language from scratch is really you also need to build out tools, IDE, debugger etc. So it is a giant project in the end. If you implement an existing language, you can piggyback in existing tools. I don't think that means existing 'common' languages are better, but that is probably why they are popular. As for choosing, it really isn't a big deal to learn a new familiar looking language to code against the flash framework we already know, so why the debate? It is probably a matter of a day or two before you would be up to speed. For Haxe is it probably a matter of an hour or two : ). I really don't see anyone having to choose one path or another. Cheers, Robin _______________________________________________ osflash mailing list [email protected] http://osflash.org/mailman/listinfo/osflash_osflash.org
