First stupid bug found and fixed! The issue was with parameters sharing the same name, e.g.
function f(a, a) {}
This gave an obscure internal error. Now it is fixed so it gives a nice "Duplicate definition of name: a" error message instead :-) It is probably not a common situation, but there is one case where I have seen it happen. Consider if someone writes:
function f(int : a, int : b) {}
Do you see the error? The parameter type and parameter name are reversed, which is a typical beginners error for developers used to C-style syntax. In this case it would lead to the previously described internal error, which would be pretty confusing. Now at least it gives a meaningful error message.
Thinking aloud: This makes me wonder though, if there should be a warning if one shadows a built-in name? E.g if I create a variable or parameter named int or String? This is actually perfectly legal in ECMAScript, but I think that in almost all real-world cases it would be a bug.
mandag den 10. november 2008
Abonner på:
Kommentarer til indlægget (Atom)
5 kommentarer:
Yes, it would be a nice value-added feature to warn (but not error) on those legal-but-probably-not-intended situations.
Great work, but I have two proposals for further ehancements:
1. compiling targets
I would like to use mascara & ECAM4 as generic plattform for programming javascript, php, ruby, python, ...
Therefore, it could be useful to have a plugin architecture that supports writing custom target code generators. (like HaXe for example)
2. Packages
Since I work a lot with ActionScript3, I got used to manage big OO-projects with classes, namespaces and packages.
And taking a look at several php frameworks: They all come with an own work-a-round for implementing packages. PHP natively does not support this feature, but obviously lots of developers need to structure big projects by using some kind of packages.
Regarding Ecma TC39 meeting in Oslo at the end of July: Some ES4 proposals made by Adobe like packages, namespaces and early binding are dropped by Google & Microsoft.
But Adobe will be going on with ECMA-Harmony. And I think, thats the right way.
I strongly believe, the mascara project should follow that branch rather than looking at the ECMA3.1 specs.
ActionScript developers are a strong and fast growing community and therefore a good target for mascara. (And don't forget about all the java developers: All of them are used to work with packages, namespaces, ... )
So what do think about these ideas for mascara releases in (near) future?
Hi Sebastian,
thank you very much for your comments!
Regarding different compilation targets: It would be fun to implement, but I'm not sure I understand what it could be used for. When would it be useful to write ES4 and translate to PHP/Python/Ruby?
Regarding packages, you have pretty much convinced me :-) I agree that some kind of module or package-system is critical for any kind of large-scale development, and I'm disappointed that packages have been left out (or at least postponed) from ES4/Harmony.
I will probably go ahead and implement packages similarly to how they are implemented in ActionScript. Since Mascara already implements namespaces, and ActionScript-style packages are just (I believe) syntactic sugar upon namespaces, it should be relatively easy to implement.
@Peter: Thanks for the support :-)
You have a good point about the value-add: Warnings and error handling is an area where a language implementation can distinguish itself without diverting from the spec.
I am also considering several levels of warning strictness, like "use strict" in Perl (but probably as a compiler option rather than a language keyword).
Hi Olav,
great, that you are thinking about implementing packages.
A simple approach could be:
(1) Define a class path root.
(2) Translate classnames:
class org.mascara.ClassA -> org_mascare_ClassA
and:
var classA:org.mascara.ClassA -> var org_mascara_ClassA
and:
import org.mascara.ClassA -> include "org/mascara/ClassA.e4s"
and: (classA instanceof org.mascara.ClassA) --> (classA instanceof org_mascara_classA)
Problems with that approach:
How to translate that statement:
package org.mascara {
class classA {
}
}
I have no idea.
And how to get the classname of an instance at runtime?
If you have a function that returns a class name, like:
function getClassName(instance):String
getClassName(classA) would return "org_mascara_ClassA", but expected output is "org.mascara.ClassA"
Again, I have no idea.
But I'm sure you will find a good way to implement the "packages" feature.
-----
The other issue "compiling targets".
I recently tried working with the meta language of "haxe.org" (some kind of ECMAScript that compiles down to JavaScript, ActionScript and PHP. Compiling targets like php come from the community. Haxe.org supports that process by providing a plugin architecture for compiling target developers.).
It is a nice idea to use just one meta language for everything. But Haxe.org has implemented less features in their ECMAScript adoption than mascara does. (And php target is still buggy).
Therefore I'd prefer going on with mascara instead.
----
But finally, if I could choose, I would definitely prefer having the "packages" feature than the "compiling targets" feature in the next mascara release.
Send en kommentar