Hi Robin, Interesting points. I too use integers for function names as opposed to their string values. I find it much faster as well. I use a customized post-processor I wrote in Java. It's amazing how fast it speeds things up. I'm curious when you mentioned storing everything in tables(arrays), what exactly did you mean? Can you provide and example. Thanks!
Cheers, Sam On Sep 13, 2007, at 7:58 AM, Robin Debreuil wrote: >> 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 _______________________________________________ osflash mailing list [email protected] http://osflash.org/mailman/listinfo/osflash_osflash.org
