I am learning ActionScript 3.0. Coming from Java world I can easily relate to strict compilation mode. I think having type safety checks at compilation time makes perfect sense.
This makes me wonder, why the compiler allows a standard mode were all the type safety checks are deferred to run time? Is compatibility with older ActionScript specification the sole reason for having standard mode?
not all functions have to be run as strictly adhering to a type at compilation, especially if running dynamicly created variables and applications. have a look at the LiveDocs page for some good examples. It is mainly a stylistic thing as far as i have found, depends on the background you are from in your coding.
I'm not sure whether this'd qualify as an answer, because who really knows exactly other than the Flash team, but my guess is that because AS3's an implementation of ECMAScript, and thus loosely typed by definition, that that's probably the main reason why there's an option for standard/loose mode.
Related
From reading revision N3242 of the c++11 draft, it appears that some components of the standard library's interfaces (notably threading and locking) depend on exception handling.
Since I do a lot of work with exceptions disabled, I am wondering which library components/features will be (practically or logically) unusable without exception handling enabled?
First of all (just as a reminder), disabling exceptions and RTTI are compiler specific extensions the Standard has no consideration for.
Since the Standard Library is usually tied to the compiler, it may be that your implementation of the Standard Library has been specifically designed to cope with this (and in particular, to cope with new returning null pointers instead of raising std::bad_alloc).
Therefore, what you ask for is non-sensical. Check the documentation of your own library for a complete list.
That being said, the Standard does guarantee that a number of operations will never throw. I don't know of any operation that swallows exceptions, I would suppose that most of them are actually safe to use as-is.
For example, all algorithms should be safe.
Still, once again, I can only recommend reading the documentation of your implementation.
This question is over one month old, and unanswered.
I am providing an answer which can be considered a community wiki, add to it as needed.
std::thread Section 30.2.2. Transitive. Abstraction implemented using native implementations.
std::mutex, std::recursive_mutex, std::timed_mutex, std::recursive_timed_mutex. Section 30.4.1, Intransitive if you supply your own exception free locking (via BasicLockable, Lockable, TimedLockable). Abstraction implemented using native implementations.
std::condition_variable Section 30.5. Transitive. Abstraction implemented using native implementations.
note: There will be more.
I'm thinking about using Haxe in place of AS3.
What are the disadventages of that? I can think about:
Difficulties with using native AS3 libraries.
Difficulity of debugging after language translation.
Haxe is quite young, it may have some rough edges. Does it?
Does any one of you have expirience with Haxe dark sides?
What are the adventages? I've heard:
Performance.
Multiple targets (But I don't see how that is useful)
Better typing that AS3
Maybe better syntax.
Haxe is big enough that there should be more. What are the pros of Haxe?
Edit:
If there are no real disadvantages then why Haxe is not replacing AS3?
Your first point is surely true. Some "native" libraries (such as Flex) may require a little of gym to be included in your project. In the vast majority of cases it is a quite smooth process. Haxe supports multiple -swf-lib which permit to have the code of the imported assets immediately available in your application. Note that the imported libs are not just embedded but are recognized as code asset, so if your IDE is integrated with Haxe you will have type completion for that too.
About the debugging there are no issues at all for the translation, that because the language is not translated to AS3 but directly compiled to AVM2 bytecode. When the -debug switch is on, the full stack trace with source code references (filename, line and position) is fully preserved. An uncaught exception will point you exactly at the line of code that generated it.
Haxe is not really that young and for sure the AVM2 output is the one with the best support of all. There are no rough edges in my opinion.
Of the pros you have outlined I want to underline that multiple targets can be huge. Of course to take really advantage of it you can't really rely on external libs specific for AS3. Even so there are always big chunks of code that you want/can reuse across projects.
To mention a few other advantages:
macros are a recent addition which add a huge pool of possibilities.
Molehill API is already available for Haxe (SVN version) and Nicolas is working on a Shader system that makes it even bigger.
Haxe is evolving constantly bringing new (important) features at each release.
Interpreted languages are usually more high-level and therefore have features as dynamic typing (including creating new variables dynamically without declaration), the infamous eval and many many other features that make a programmer's life easier - but why can't compiled languages have these as well?
I don't mean languages like Java that run on a VM, but those that compile to binary like C(++).
I'm not going to make a list now but if you are going to ask which features I mean, please look into what PHP, Python, Ruby etc. have to offer.
Which common features of interpreted languages can't/don't/do exist in compiled languages? Why?
Whether source code is compiled - to native binaries, some kind of intermediate language (Java Bytecode/IL) - or interpreted is absolutely no trait of the language. It's just a question of the implementation.
You can actually have both compilers and interpreters for the same language like
Haskell: GHC <-> GHCI
C: gcc <-> ch
VB6: VS IDE <-> VB6 compiler
Certain language features like eval or dynamic typing may suggest a distinction between so called "dynamic languages" and static ones, but how this is run can never be the primary question.
Initially, one of the largest benefits of interpreted languages was debugging. That way you can get incredibly accurate and detailed information when looking for the reason a program isn't working. However, most compilers have become advanced enough that that is not too big of a deal any more.
The other main benefit (in my opinion anyway), is that with interpreted languages, you don't have to wait for eternity for your project to compile to test it out.
You couldn't plausibly do eval, for example, for reasons I'd have thought were pretty obvious: exactly how would you implement it? Make the runtime contain a full copy of the compiler? Every time you wanted to evaluate a string (keeping in mind that each time it could be different!) you'd save the string to a file, run the compiler on it to make a DLL/shared-lib, then load that DLL/shared-lib and call your code? You can't see why this might be a wee bit impractical? ;)
You can find this kind of thing in dynamic languages all over the place that you can't do with static code short of basically running an interpreter, in effect, behind the scenes.
Continuing on from Dario - I think you are really asking why a compiled program can't evaluate statements at runtime (e.g. eval). Here's some reasons I can think of:
The full compiler would have to be distributed with the program (or be part of the program)
For an eval function to have access to type information and symbols (such as variable names and function names) in the environment it was used the original program would have to be compiled with those symbols accessible (compiled languages usually remove these symbols at compile time).
Edit: As noted neither of these reasons make it impossible for a language/compiler to be able to evaluate code at runtime, but they are definitely things that need to be taken into consideration when developing a compiler or when designing a language.
Maybe the question is not about interpreted/compiled languages (compile is ambiguous anyway) but about languages that do/don't carry their own compiler around with them? For instance we've said C++ could do eval with a handy compiler floating around in the app, and reflection presumably is similar in some ways.
I see a lot of AS3 libraries are written in strict mode compile fashion. They are all very Java like. I haven't seen any libraries that requires compilation in normal mode. More functional programming like, and probably use a lot of prototype and scoping magic, since ActionScript 3 can be very much JavaScript like if used normal mode compilation.
In many cases, functional style programming can be more powerful IF used correctly, and thus produce more elegant code.
My question is that is there any library in AS3 that dares to for go the bondage of strict mode, and uses normal mode?
I think that writing code only to compile in normal mode it's actually easy. If anyone should choose this, it might be because of lack of time, but will only (eventually) lead to "rushed" code.
The actual DARE is to write proper, robust, strict AS3 code.
Anyone who has programmed with actionscript 3.0 has most certainly noticed its lack of support for private constructors and abstract classes. There are ways to work around these flaws, like throwing errors from methods which should be abstract, but these work arounds are annoying and not very elegant. (Throwing an error from a method that should be abstract is a run-time check, not compile-time, which can lead to a lot of frustration).
I know actionscript 3.0 follows the current ECMAscript standard and this is the reason for its lack of private constructors, but what about abstract classes, are they not in the ECMAscript standard eather?
I guess the more specific question is why does ECMAscript standard not support private constructors? Is it something that can be look forward to in the future?
I have been wondering this for quit sometime, any insight will be much appreciated.
private constructors and abstract classes are not "good OOP elements". they're nice hacks originated in C++. in more dynamic languages they're usually not needed.
abstract classes in particular are totally unneeded, since you don't have to declare the interface in the ancestor to comply with an interface. in fact, you don't even have to inherit from a common ancestor to use some polymorphism.
i'm not saying that AS is better without something like that; rather that you should think in the language you're using, not trying to translate from whatever you're used to.
Neither private constructors nor abstract classes were defined in the old ECMAScript 4 standard on which ActionScript 3 was based. If I remember correctly, the ECMAScript Working Group chose not to implement these more complicated OOP features because there was a certain focus on simplicity and backwards compatibility with older versions of ECMAScript. I interpreted what I heard from them as "we may add these features later, but let's take it slowly". The abstract keyword, for example, is a reserved word, so they have this stuff in mind.
It's worth noting that the working group has chosen to restart the next version of the language with a new focus. This effort is called "Harmony" because two rival sub-groups had very different opinions about where ECMAScript should go in the future. It's a bit of a compromise. Harmony is going to progress much more slowly than the old ES4, and even the class syntax that was already implemented in AS3 will be dropped from the standard initially. In other words, they're going to keep it looking a lot more like today's JavaScript for a while to focus on some other features that are important to the group that was going to branch. This will become ES3.1. Later, classes and some of the more Java-like OOP features will be reconsidered for a new ES4.
What about AS3, though? Basically, Adobe jumped the gun by using a standard that wasn't yet complete, and they got bit by politics. However, Adobe intends to stay involved with the ECMAScript Working Group, and they will likely consider adding features that the working group recommends. That said, AS3 may never be a complete (or fully compatible) implementation of a future ECMAScript. What does that mean? Well, since they're non-standard again, Adobe has the option to add features to ActionScript, even if those features aren't part of a standard. If you feel abstract classes or private constructors are important to you as a developer, request these features in the public Flash Player bug database, or vote for existing feature requests, if they're already present.
I know, this question is really old, but I just stumbled accross and had to amend this:
Constructors are not OO. Objects should be instantiated by factories.
Abstract classes are not OO. Instead one should use interfaces (which AS3 has) and mixins (which AS3 doesn't have).
AS3 is a poor language, but for many more fundamental reasons than these two. AS3 basically is a structured representation of AVM2 bytecode. A 1:1 mapping is easily feasible. And I suppose, it's likely to stay like that, because Adobe appearently has more interest in driving forward platform features, their commercial authoring tools and the flex framework (including mxml).
greetz
back2dos