New Feature to JS 1.7
JS1.7 shipped in Firefox 2 and it is "done". This list is for
discussion of ECMA-262 Edition 4 (ECMAScript 4, es4) features and
design decisions. See www.ecmascript.org.
The docs for ES3 are gonna be updated?
Including some changes to the spec?
On Sep 24, 2007, at 10:51 AM, Garrett Smith wrote:
The docs for ES3 are gonna be updated?
No commitment from the group yet to do this.
Including some changes to the spec?
Again no commitment yet from TG1 to pursue this.
I personally believe that the unsound, untestable/non-executable ES3
spec is a rathole we should avoid. The errata (which are not complete
by a long shot) that we have hosted at www.mozilla.org/js
language/E262-3-errata.html would have to be incorporated, again with
high risk of bugs and no way to test. I think we are much better off
working on the ES4 refimpl and the spec derived in part from it.
As js4 will support OOP natively, this feature will useless for it but for js1.7 it will be usefull. In js1.7 I can not call next function from prototype chain For example: function A(){}; A.prototype.f1= function(){}; function B(){}; B.prototype= new A(){}; B.prototype.f1= function(){ /How call f1 from prototype A?/} There will be usefull to have next property:
B.prototype.f1= function() { arguments.inherit( this, arguments ); /*use full feature to call next function in prototype chain */ }; ----- Original Message ---
Your best bet for js1+ is to use one of the many class-like
frameworks, prototype, dojo, or my favorite, [OpenLaszlo](http://
pt.withy.org/ptalk/archives/2006/05/circles_and_arrows.html). We
implement nextMethod with annotation on the method function objects.
Sorry for my English
We implement
nextMethodwith annotation on the method function objects
When will you implement 'nextMethod'?
----- Original Message ---
I am saying that the OpenLaszlo framework implements a class system
on top of JS1 (as do many other AJAX frameworks). I don't expect JS1
to ever support this natively. As you wrote, that is what JS2 is for.
On 9/25/07, Eugen.Konkov at aldec.com <Eugen.Konkov at aldec.com> wrote:
B.prototype.f1= function(){ /How call f1 from prototype A?/}
B.prototype.f1= function(){A.prototype.f1.call(this)}
It's nasty, but works if f1 is from prototype of A but not from the constructor of A.
Maybe every Ajax framework provide their own super call based on this trick, but some are buggy, such as DC's uber (see johnhax.blogspot.com/2006/12/bug-of-douglas-crockfords-uber.html).
It's nasty, but works if f1 is from prototype of A but not from the constructor of A.
Even more it is hardcoded, so if you change name 'A' to 'A1' you must change everywhere in your code. OpenLaszlo ](pt.withy.org/ptalk/archives/2006/05/circles_and_arrows.html) implementation of a class system is the best I have seen ever
----- Original Message ---
On 9/24/07, Brendan Eich <brendan at mozilla.org> wrote:
On Sep 24, 2007, at 10:51 AM, Garrett Smith wrote:
The docs for ES3 are gonna be updated?
No commitment from the group yet to do this.
Including some changes to the spec?
Again no commitment yet from TG1 to pursue this.
I personally believe that the unsound, untestable/non-executable ES3 spec is a rathole we should avoid. The errata (which are not complete by a long shot) that we have hosted at www.mozilla.org/js language/E262-3-errata.html would have to be incorporated, again with high risk of bugs and no way to test. I think we are much better off working on the ES4 refimpl and the spec derived in part from it.
That is disappointing to hear.
I sent an email to helpdesk at ecma.ch, as it is listed on the front of the manual, but did not get a reply.
If the documentation were amended, understanding would most likely improve.
BTW, I'm having trouble viewing ecmascript.org now.
Garrett
On Oct 7, 2007, at 11:41 PM, Garrett Smith wrote:
I personally believe that the unsound, untestable/non-executable ES3 spec is a rathole we should avoid. The errata (which are not complete by a long shot) that we have hosted at www.mozilla.org/js language/E262-3-errata.html would have to be incorporated, again with high risk of bugs and no way to test. I think we are much better off working on the ES4 refimpl and the spec derived in part from it.
That is disappointing to hear.
Why? Which particular word in "unsound", "untestable" and "rathole"
was wrong, so that you'd be disappointed we didn't charge down that
tunnel?
I sent an email to helpdesk at ecma.ch, as it is listed on the front of the manual, but did not get a reply.
That mail made it to my attention. The problem besides the lack of
soundness and testability is that editing minor corrections can be
done, but creates a difference between the Ecma spec and the ISO
version of it. Editing non-trivial fixes is not well-supported by
Ecma process or JTC-1 Fast-track to ISO.
The fix is to do a new Edition, but that's not going to happen just
to fix a few (or even a lot of) errata. It has been over eight years
since Edition 3, and the JS authors deserve better than a typo fix or
three. Our work on Edition 4 is all but specified. Meaning, we're
about ten months from really all but done with the spec -- spec-
writing is hard work, but at least this time there will be a testable
reference implementation provided along with the spec, and bug-fixed
over time.
Modern standards are not holy writ, and as you note not bug-free.
They should move toward continual refinement and release, as software
has (Windows Update, Apple Software Update, etc.). The Ecma process
is not nearly that continual. The Scheme community wants to move
toward a more frequent update of their spec (R6RS, R6.1RS, etc.). I'm
working with Ecma folks to explore a way forward along those lines,
but it won't happen quickly. The best plan now is to get back to an
every-two-years release footing, based on ES4.
If the documentation were amended, understanding would most likely
improve.
Maybe, but there're lots of JS books on shelves and people cope
without delving into the corners of the spec that contain errata. We
get very few complaints -- yours is one of a few cases where someone
bothered to mail Ecma.
BTW, I'm having trouble viewing ecmascript.org now.
Works for me at the moment.
On 10/8/07, Brendan Eich <brendan at mozilla.org> wrote:
On Oct 7, 2007, at 11:41 PM, Garrett Smith wrote:
I personally believe that the unsound, untestable/non-executable ES3 spec is a rathole we should avoid. The errata (which are not complete by a long shot) that we have hosted at www.mozilla.org/js language/E262-3-errata.html would have to be incorporated, again with high risk of bugs and no way to test. I think we are much better off working on the ES4 refimpl and the spec derived in part from it.
That is disappointing to hear.
Why? Which particular word in "unsound", "untestable" and "rathole" was wrong, so that you'd be disappointed we didn't charge down that tunnel?
I sent an email to helpdesk at ecma.ch, as it is listed on the front of the manual, but did not get a reply.
That mail made it to my attention. The problem besides the lack of soundness and testability is that editing minor corrections can be done, but creates a difference between the Ecma spec and the ISO version of it. Editing non-trivial fixes is not well-supported by Ecma process or JTC-1 Fast-track to ISO.
The fix is to do a new Edition, but that's not going to happen just to fix a few (or even a lot of) errata. It has been over eight years since Edition 3, and the JS authors deserve better than a typo fix or three.
True.
Our work on Edition 4 is all but specified. Meaning, we're
about ten months from really all but done with the spec -- spec- writing is hard work, but at least this time there will be a testable reference implementation provided along with the spec, and bug-fixed over time.
Modern standards are not holy writ, and as you note not bug-free. They should move toward continual refinement and release, as software has (Windows Update, Apple Software Update, etc.).
That is why IE is so far behind -- they dump a browser every 3 years, then process bug rept's for the next 2 years, gathering information for the next iteration.
It's also why the other browsers are advancing faster. Shorter release cycles, public bug tracking, and Software update.
The Ecma process
is not nearly that continual. The Scheme community wants to move toward a more frequent update of their spec (R6RS, R6.1RS, etc.). I'm working with Ecma folks to explore a way forward along those lines, but it won't happen quickly. The best plan now is to get back to an every-two-years release footing, based on ES4.
Shorter release cycles help to continually improve quality.
If the documentation were amended, understanding would most likely improve.
Maybe, but there're lots of JS books on shelves and people cope without delving into the corners of the spec that contain errata. We get very few complaints -- yours is one of a few cases where someone bothered to mail Ecma.
But it's not just books! Browser QA should be able to ascertain if the implementation is correct of not.
But since ES4 covers ES3, the manual will, too, and will correct problems in ES3.
BTW, I'm having trouble viewing ecmascript.org now.
Works for me at the moment.
It looks like the problems of the ES3 spec are being positively addressed. Shorter release cycles and tests. One more thing that would help immensely: Interlinked HTML Format for the official release.
Garrett
Hello Where can I post request for new feature to JavaScript 1.7?