some errata in PDF

# Garrett Smith (18 years ago)

PDF Spec:

Pages 163 - 168

Methods are not alphebetized. Many methods missing.

Page 163: Missing: Object.prototype.superclass ?

Missing: Function.prototype.caller Function.prototype.name ?

Duplicate: Function.prototype

Missing: Array extras Array.prototype.length Wrong: Array.length (the Array Function gets length off function.prototype)

Page 165: Missing: String.prototype.trim

Page 166 Date.prototype.toLocaletimeString

should be Date.prototype.toLocaleTimeString

Page 63: 10.2.1 Line 27 references a non-existant variable 'b'

# liorean (18 years ago)

On 26/08/07, Garrett Smith <dhtmlkitchen at gmail.com> wrote:

Missing: Function.prototype.caller

Should this property really be on the prototype? Even placing it on the Function instances alone seems a bad idea to me, since the value is per call and not per function object. But placing it on the Function prototype seems an even worse idea. It should really be a property on the function object only for compatibility reasons in engines which have to use it (and even then only exist while the function is executing).

Function.prototype.name ?

Makes more sense - the Function prototype is a function per ES3, so if function instances should have a name property, then the Function property should probably have it as well. IIRC ES3 doesn't specify it, but it's in the browser hosted engines.

# Garrett Smith (18 years ago)

On 8/25/07, liorean <liorean at gmail.com> wrote:

On 26/08/07, Garrett Smith <dhtmlkitchen at gmail.com> wrote:

Missing: Function.prototype.caller

Should this property really be on the prototype?

It's useful for two cases:

  1. Debugging
  2. enforcing an entry point to a constructor.

The second use case is useful when trying to enforce a private constructor by making a runtime check to the calling function. The perfectly valid use case of trying to have a private constructor, will not, unfortunately be accommodated by ES4; the ugly run-time approach or the module pattern will not be ameliorated.

Regarding access-modified constructors, ES4, Section 9.6.1 states: "While other languages allow constructors methods (grammar error not mine) to be inaccessible to keep outside code from creating instances, this use case was not deemed important enough to complicate the language design."

However, enforcing a singleton has lead to strangeness such as runtime checking of the caller (case#2 above) and the "module pattern".

Back to "caller"... "caller" is on the prototype in Mozilla. Not sure where it is in IE, prototype or instance.

On the instance in WebKit.

Absent in Opera.

# Lars T Hansen (18 years ago)

On 8/26/07, Garrett Smith <dhtmlkitchen at gmail.com> wrote:

developer.mozilla.org/es4/spec/spec.html

Bottom of the page.

I found that it was convenient for printing.

Am I'm reading another out-of-date spec?

Very. This is the baseline spec, derived from the ActionScript 3 spec, somewhat updated (maybe) but not current in any sense that I'm aware of.

Everyone, I'm removing the link to this spec, the confusion of having it there does us no good.

# Lars T Hansen (18 years ago)

On 8/26/07, Lars T Hansen <lth at acm.org> wrote:

On 8/26/07, Garrett Smith <dhtmlkitchen at gmail.com> wrote:

developer.mozilla.org/es4/spec/spec.html

Bottom of the page.

I found that it was convenient for printing.

Am I'm reading another out-of-date spec?

Very. This is the baseline spec, derived from the ActionScript 3 spec, somewhat updated (maybe) but not current in any sense that I'm aware of.

Everyone, I'm removing the link to this spec, the confusion of having it there does us no good.

Following up to myself, the page is on the exported wiki so there's not much I can do about it.

Everyone, that wiki export is completely out of date. The only wiki to pay attention to is wiki.ecmascript.org.

Brendan/Graydon, perhaps you can remove this old export now that we have the new wiki readable by everyone.

# liorean (18 years ago)

On 26/08/07, Garrett Smith <dhtmlkitchen at gmail.com> wrote:

Missing: Function.prototype.caller

On 8/25/07, liorean <liorean at gmail.com> wrote:

Should this property really be on the prototype?

On 26/08/07, Garrett Smith <dhtmlkitchen at gmail.com> wrote:

It's useful for two cases:

  1. Debugging
  2. enforcing an entry point to a constructor.

Neither of these cases seems to have anything at all to do with the prototype, if you ask me. I don't see why you would ever want to access the caller property on the prototype. The property is not useful for the prototype itself (which is a function of zero formal parameters with an empty function body returning nothing) since the only case you could access it is from a called function, and the prototype having an empty function body means it does not access it when called, so there is absolutely no need for it. Nor would it be useful for function instances to delegate to the prototype, since the value is only interesting per instance. Even further, it's not really appropriate to have it on the function object of instances at all, since it only makes sense when the function has been called, i.e. in the function body itself.

A much more sensible place to put it is on the arguments object, since that is per instance, per call. Having it on the function object at all is itself simply bad design coming from Netscape's hurried implementation. It being accessible through the function object is a language wart, plain and simple.

# Lars T Hansen (18 years ago)

On 8/26/07, Garrett Smith <dhtmlkitchen at gmail.com> wrote:

The perfectly valid use case of trying to have a private constructor, will not, unfortunately be accommodated by ES4;

Now filed as bug 166 in the Trac.

# Lars T Hansen (18 years ago)

On 8/26/07, Garrett Smith <dhtmlkitchen at gmail.com> wrote:

Back to "caller"... "caller" is on the prototype in Mozilla. Not sure where it is in IE, prototype or instance.

On the instance in WebKit.

Absent in Opera.

Absent in ES3. Absent in ES4.

function f() { // I wonder how my caller was invoked? Maybe he has secrets from me? xs = f.caller.arguments // Maybe I can trick my caller into doing something bad by munging his state? f.caller.arguments[1] = 37 // I wonder what the code of my caller is? code = f.caller.toString() }

Retch. Granted the content distribution and security models of the web make this kind of attack much less potent, and some of the introspection functionality proposed for ES4 may have similar issues (not clear to me yet), but "caller" has a lot of problems.

# Brendan Eich (18 years ago)

On Sep 3, 2007, at 3:00 AM, Lars T Hansen wrote:

On 8/26/07, Garrett Smith <dhtmlkitchen at gmail.com> wrote:

Back to "caller"... "caller" is on the prototype in Mozilla.

Not lately:

js> function f(){ return f.hasOwnProperty('caller')}

js> f()

This is a SpiderMonkey REPL based on code going into Firefox 3.

Retch. Granted the content distribution and security models of the web make this kind of attack much less potent, and some of the introspection functionality proposed for ES4 may have similar issues (not clear to me yet), but "caller" has a lot of problems.

That's why it was never standardized. It was a bogo-reflection from
Netscape 2. That it's not in JScript says to me that other
implementations can drop it. Mozilla 2 won't support it, FYI.

# Brendan Eich (18 years ago)

On Sep 3, 2007, at 7:10 PM, Brendan Eich wrote:

On Sep 3, 2007, at 3:00 AM, Lars T Hansen wrote:

On 8/26/07, Garrett Smith <dhtmlkitchen at gmail.com> wrote:

Back to "caller"... "caller" is on the prototype in Mozilla.

Not lately:

js> function f(){ return f.hasOwnProperty('caller')} js> f()

true

(was the line I failed to include in that copy/paste.)

# Garrett Smith (18 years ago)

On 8/26/07, Lars T Hansen <lth at acm.org> wrote:

On 8/26/07, Garrett Smith <dhtmlkitchen at gmail.com> wrote:

developer.mozilla.org/es4/spec/spec.html

Bottom of the page.

I found that it was convenient for printing.

Am I'm reading another out-of-date spec?

Very. This is the baseline spec, derived from the ActionScript 3 spec, somewhat updated (maybe) but not current in any sense that I'm aware of.

Is there a version of the spec that's printable as one document?

It is easier for me tor read these docs printed out on paper.

Everyone, I'm removing the link to this spec, the confusion of having it there does us no good.

Go to: www.ecmascript.org/docs.php

click: ECMAScript Edition 4 Wiki

this will take you to: developer.mozilla.org/es4

Where you can click on the outdated specification, download it, print it out (hey, trees aren't free), and absorb the knowledge of an out-dated spec.

Where, if it exists, is the indication that any of this is out of date?

Garrett

# Lars T Hansen (18 years ago)

On 9/5/07, Garrett Smith <dhtmlkitchen at gmail.com> wrote:

On 8/26/07, Lars T Hansen <lth at acm.org> wrote:

On 8/26/07, Garrett Smith <dhtmlkitchen at gmail.com> wrote:

developer.mozilla.org/es4/spec/spec.html

Bottom of the page.

I found that it was convenient for printing.

Am I'm reading another out-of-date spec?

Very. This is the baseline spec, derived from the ActionScript 3 spec, somewhat updated (maybe) but not current in any sense that I'm aware of.

Is there a version of the spec that's printable as one document?

No. Printable documents will be released as they become available; announcements will be made to this list.

It is easier for me tor read these docs printed out on paper.

Everyone, I'm removing the link to this spec, the confusion of having it there does us no good.

Go to: www.ecmascript.org/docs.php

click: ECMAScript Edition 4 Wiki

this will take you to: developer.mozilla.org/es4

Where you can click on the outdated specification, download it, print it out (hey, trees aren't free), and absorb the knowledge of an out-dated spec.

Where, if it exists, is the indication that any of this is out of date?

You're expected to know :-) :-)

We'll need to fix this.