Sam, To continue on your Vector / CLR arrays conversation. Adobe should support CLR typed static arrays and have a separate Vector -or- Stack type for dynamic lengths. Regardless of performance, CLR typed arrays force better programming practices and simply make debugging easier. It is disheartening to see "arr.pop() as mytype or mytype(arr.pop())" all over my code just so i can properly compile, debug my app against the true data type expected from the array.
As far as the whole "abstract" class argument goes, I simply feel that the keyword just provides better compile time support for frameworks. I would rather get a compiler error than a runtime error that has to be tracked down. Not to mention all the extra runtime code you have to run to verify the abstract status and AbstractErrors you have to throw. ciao -Jon On 9/12/07, Samuel Agesilas <[EMAIL PROTECTED]> wrote: > > Hi Zwetan, > > If a language is not up to par, than we should have the ability to > improve it. If that means we have to deviate from a spec... who > cares? The ECMA specification is not law... who cares what a small > group of people who probably have never even used the language in a > real world project think about the specification. Again it goes back > to the ivory tower thing. What are we mindless drones that blindly > follow what Adobe says about an ECMA spec. Anyway to answer your > points... > > > 1. You CAN code using MTASC and have your code be interoperable > between the FLASH IDE Compiler and MTASC. I've done it many times > myself. If you want to be compatible with the FLASH IDE then don't > use the MTASC specific language features. > > 2. Ok I fail to see the connection with the MSDN articles. What > Microsoft calls Dynamic Arrays behave like Vectors of a generic type. > > http://en.wikipedia.org/wiki/Vector_%28STL%29 > > Furthermore microsoft admits in the very artices you posted that > these type of "dynamic arrays" are not as optimal as the statically > typed arrays the CLR can use. Here's a quote from your article... > > "Well, the CLR implementers knew that dense, nonassociative hard- > typed arrays are easy to make fast and efficient. Furthermore, such > arrays encourage the programmer to keep homogenous data in strictly > bounded tables. That makes large programs that do lots of data > manipulation easier to understand. Thus, languages such as C++, C# > and Visual Basic have arrays like this, and thus they are the basic > built-in array type in the CLR." > > This is my point! AS3 is sacrificing performance because Adobe thinks > its easier to use dynamically typed arrays ( vectors ). The REAL > statically typed one. What are we idiots to them? > > 3,4,5,6. Be careful what you wish for. Sure a dynamic language may > SEEM to give you more freedom, but once you start building really > large projects with it you'll notice you'll notice when it's time to > debug a lot of time your left out in the cold. Languages like C# and > Java have managed to fine a nice balance between the two. Java > introduced Generics a while back to add a modicum of dynamism to the > Java programming platform. However when you are doing smaller > projects then yes I can see the appeal of a more dynamic set of > features. Personally I prefer a more structure stricter language that > allows me vigorously debug any problems that may occur. Another > argument for stricter languages is that they are much easier to > maintain then dynamic ones. Cause the code provided, reveals more > information about itself than in dynamic ones. > > Cheers, > Sam > > > On Sep 12, 2007, at 1:53 AM, zwetan wrote: > > > Hi Samuel, > > > > On 9/11/07, Samuel Agesilas <[EMAIL PROTECTED]> wrote: > >> Zwetan, > >> > >> I agree with Nicolas, if you take for instance MTASC, IMHO opinion it > >> produces better optimized byte code than the old Macromedia Flash > >> compiler itself and that is one of the great things about having an > >> open source compiler. The community can get involved and make it > >> better. As for more basis for saying that Actionscript 3 really is an > >> immature language is as follows.... > >> > > > > I don't agree at all here > > > > here my points: > > > > a) a compiler and the resulting bytecode are two very distinct things > > you may optimize the bytecode output, but you just can't add features > > to this bytecode or you become incompatible > > > > so when you're talking about an open source compiler, > > if the goal is to compile better bytecode (optimized, faster, etc.) > > then yes I do agree, the same as different C compilers have different > > optimization tricks, I have no problem with different actionscript > > compilers > > using different trick to optimize the bytecode, > > but with the concern that the bytecode HAVE TO be compatible. > > > > but if the goal of this open source compiler is to have a way to > > change the > > language features set (for whatever reasons), > > then iI don't agree at all, this force developpers to learn a new > > language > > that is not the same (differente features, different construct, etc.) > > even if the compiler make it compile to the same bytecode. > > > > b) so yeah let's take MTASC for instance > > > > if you programm for MTASC, your source code can not compile with the > > Flash IDE compiler. > > > > So, that means if you start to compile for MTASC, you have no way > > back, > > you are locked in the MTASC logic, MTASC way of doing thing etc. > > > > thanks, but no thanks. > > > > I base my knowledge of languages on standard and spec, not made up > > language. > > > > To briefly resume my main grief: > > - AS2 is a syntax wrapper over the ECMA-262 3rd spec > > but using the Flash compiler you can compile both AS1 syntax and > > AS2 syntax > > at the same time > > - MTASC define a modified version of the AS2 language > > and do not support at all the ECMA-262 3rd spec > > > > being able to reuse the knowledge of a spec among different > > languages that implement that spec is more important to me. > > > > > >> 1. Arrays or non existent in Actionscript. I know Adobe claims to > >> have Arrays but Arrays in Actionscript are not Arrays they are > >> Vectors and that is a HUGE distinction. Vectors while more flexible > >> and easier to use are slower and consume more memory. > >> > >> for example in Java you would declare in arrray like so... > >> > >> n = int[10] > >> > >> if you try to access index 11 in array n, an IndexOutOfBounds > >> Exception is thrown. Same for C#, Objective C and obviously C. This > >> is fundamental and basic to all professional languages and > >> Actionscript 3 doesn't have it? Why? Who knows but it's not there. > >> > > > > look at the links I provided to another answer about > > Type parameters in ES4 > > > > in short, a language based on ES4 final spec will be able to do that > > ---- > > var stringArray:Array.<String> = new Array.<String>; > > ---- > > > > here some article about those dynmaic arrays that you call vectors > > http://blogs.msdn.com/ericlippert/archive/2003/11/10/53376.aspx > > http://blogs.msdn.com/ericlippert/archive/2003/11/12/53377.aspx > > http://blogs.msdn.com/ericlippert/archive/2003/11/21/53399.aspx > > http://blogs.msdn.com/ericlippert/archive/2003/12/05/53452.aspx > > > > AS3 does not allow it yet, but the VM(Tamarin) can support it, > > and the ES4 spec plan for such typed array. > > > > > > > >> 2. No method overloading. The reason for this is that The VM does > >> not store detailed enough method signatures at runtime. Meaning that > >> while obviously the name and the modifiers are stored ( public, > >> private, namespace, etc ). It does not store information about method > >> arguments like Java does. It uses a very arcane method borrowed from > >> Javascript of using indices instead of the actual argument name. > >> Again in Java you can the declare the following... > >> > >> setName( String name ); > >> setName( String f_name, String l_name ); > >> > >> In the same class and they are treated completed different because > >> Java recognizers the argument type. While Actionscript just using > >> argument order which is just ridiculous, IMHO. > >> > > > > no, what is ridiculous is to think in Java or C# in a dynamic language > > such as ActionScript 3. > > > > I prefer 100 times to have: > > - class defined method taking precedence over prototype defined > > methods > > - a rest argument > > - namespaces > > > > than overloaded methods, > > but the only way to understand that is to have a dynamic approach to > > programming. > > > > I kind of being sick that people try to make AS3 work like Java, > > AS3 is not Java, that's it, and in AS4 the differences would show > > even more. > > > > > >> 3. Actionscript 3 does not have support for Abstract Classes > >> > > > > that's normal, AS3 is still a prototype based language. > > > > again, not the same logic as a static language. > > > > > >> 4. Actionscript 3 does not support private constructors.... This is a > >> huge problem Actionscript 2 did, and now Actionscript 3 does not. For > >> the life of me I don't get that decision at all. > >> > > > > see my other answer where I explain why it's like that. > > > > > >> 5. Actionscript 3 does not support native Enums like Java and C++./C# > >> do. > >> > > > > big deal... > > > > native enums are not the panacea, sure it's convenient on the > > syntax level, > > but nothing prevent you in AS3 to do typedef enums > > > > see > > Chapter 5, "Substitutes for C Constructs > > http://java.sun.com/docs/books/effective/chapters.html > > http://developer.java.sun.com/developer/Books/effectivejava/ > > Chapter5.pdf > > > > also see > > http://calculist.blogspot.com/2006/05/customized-literals-in- > > ecmascript-4.html > > and > > http://wiki.ecmascript.org/doku.php?id=spec:chapter_6_types > > > > > > > > > >> 6. Try Catch exceptions are not forced. Meaning if a calling method > >> implements a throws method unlike in Java, in Actionscript 3 you do > >> NOT have to surround the calling method with a try...catch block. > >> > > > > yeah ... well at least I will not be forced to classify any method > > than can throw > > as throwable > > > >> > >> Everything that I mentioned above is pretty basic stuff. When I > >> switch from a more robust language like C++ or Java and go back to > >> Actionscript 3 I feel like I'm coding in Javascript... LOL. Don;t get > >> me wrong I absolutely love Flash. Java sucks big time when it comes > >> to displaying anything on the screen that looks cool! And Flash wins > >> that battle every-time but, let's "Keep it Real" here... while > >> Actionscript 3 is far better than Actionscript 2, it still lags > >> behind other languages for no real apparent reason. > >> > > > > what you call robust languages are bondage and discipline languages :) > > > > a dynamic language give you more freedom, > > and implementation as AS3 can give you both: > > freedom when you need it, and discipline when you need it > > > > something that a language like Java can not do > > > > > >> Another gripe I have is with the developer tools that we get from > >> Adobe. Being a long time GCC and javac user when I have to use mxmlc, > >> I feel like pulling my hair out. Fcsh, is a perfect example of a tool > >> that shows promise but is really crappy to use and since we don't > >> have access to the source code for fcsh the flash community can't fix > >> any of the numerous problems it has. So we have to wait until Adobe > >> decides to fix the problem ( assuming they acknowledge a problem > >> exists! ). Making an open source compiler and tools allow us ( the > >> community ), to deal with these issues in the way we see fit. > >> > > > > my point was, why making another compiler when the original > > compiler (ASC) > > is planed to be open sourced > > > > and please don't compare apples with oranges, > > GCC and javac didn't happen yesterday, > > it's a little bit unfair to judge mxmlc from its short lifespan > > > > cheers, > > zwetan > > > > _______________________________________________ > > 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 >
_______________________________________________ osflash mailing list [email protected] http://osflash.org/mailman/listinfo/osflash_osflash.org
