ES4 draft: the global object
Draft 2 (fairly small changes, but this version went to the TC last week). I would in particular like comments on eval.
2008/3/24 Lars Hansen <lhansen at adobe.com>:
I would in particular like comments on eval.
Why does the operator form of eval have the name 'intrinsic::eval' (in addition to plain 'eval')? Either eval has the distinction of being the only namespaced operator in the language, or else this is a pun. Either way, I don't see the justification. Backwards compatibility can't be the issue, since ES3 doesn't have namespaces.
There are some global functions that I think should be deprecated and moved to a relevant class.
encodeURIComponent et al have nothing to do with the Global object.
Same with isNaN, isFinite.
These should be deprecated and moved to the appropriate object. In the case of encodeURIComponent, that would be a URI object, and ideally one that would encapsulate useful behavior (not a mishmash of static methods, e.g. Math).
Garrett
2008/3/12 Lars Hansen <lhansen at adobe.com>:
Deprecation does not really buy you anything. Most people will never know something is deprecated and even if they do, they will most likely continue to use it. (Take escape and unescape as example.)
Yes, it would be nice to have a Uri class but that can be implemented by libraries and eventually become part of the defacto standard libraries.
On Tue, Mar 25, 2008 at 7:50 AM, Erik Arvidsson <erik.arvidsson at gmail.com> wrote:
Deprecation does not really buy you anything. Most people will never know something is deprecated and even if they do, they will most likely continue to use it. (Take escape and unescape as example.)
No, actually, if you deprecate something, and provide a better alternative, you can remove the deprecated thing later.
Take Object.prototype.eval, for example. Nobody uses that much anymore. If it's removed from Mozilla, probably some pages will break, but not that many. Most people know better than to use that. I'm surprised it's been hanging around in for so long.
Garrett
<sniip>
On Tue, Mar 25, 2008 at 07:12, Garrett Smith <dhtmlkitchen at gmail.com> wrote:
<snip>
Take Object.prototype.eval, for example. Nobody uses that much anymore. If it's removed from Mozilla, probably some pages will break, but not that many. Most people know better than to use that. I'm surprised it's been hanging around in for so long.
Most people don't know about Object.prototype.eval and it was only available in Spidermonkey. That is why no one relied on it.
On Mar 25, 2008, at 8:05 AM, Garrett Smith wrote:
Take Object.prototype.eval, for example. Nobody uses that much anymore. If it's removed from Mozilla,
It has been removed -- test Firefox 3, any beta.
-----Original Message----- From: Garrett Smith [mailto:dhtmlkitchen at gmail.com] Sent: 25. mars 2008 08:06 To: Erik Arvidsson Cc: Lars Hansen; es4-discuss at mozilla.org Subject: Re: ES4 draft: the global object
On Tue, Mar 25, 2008 at 7:50 AM, Erik Arvidsson <erik.arvidsson at gmail.com> wrote:
Deprecation does not really buy you anything. Most people will never know something is deprecated and even if they do, they will most likely continue to use it. (Take escape and unescape as example.)
No, actually, if you deprecate something, and provide a better alternative, you can remove the deprecated thing later.
Actually, if you deprecate something and provide a better alternative you can keep reducing the quality of the old something almost indefinitely, but it's questionable that you can ever remove it since you can't in general know whether content relies on it. This seems especially true for script content, in which property names can be computed at run-time.
So far the ES4 WG has accepted one deprecation, for the arguments object (because rest arguments and "this function" provides the same functionality in a cleaner way). But it took a lot of arm twisting, and the reality is that the deprecation really isn't worth anything and the spec probably ought not say that the feature is deprecated.
The changes you suggest are simple to make but the only effect to the language is bloat (more features rather than fewer). It's not like the language will be easier to use just because there's a new way to reference isNaN.
On Tue, Mar 25, 2008 at 8:13 AM, Erik Arvidsson <erik.arvidsson at gmail.com> wrote:
Take Object.prototype.eval, for example. Nobody uses that much anymore. If it's removed from Mozilla, probably some pages will break, but not that many. Most people know better than to use that. I'm surprised it's been hanging around in for so long.
Most people don't know about Object.prototype.eval and it was only available in Spidermonkey. That is why no one relied on it.
It is true that that is an old feature and one that didn't catch on as much as escape/unescape. IT did get a fair amount of use c1999, where scripts would have code for IE using document.all and netscape using document.eval.
Nobody does that anymore. It is evidence of a feature that was deprecated and has now been removed in Firefox 3.
WRT escape, that has seen much less use lately. All the libraries are using encodeURIComponent and they don't even have a fallback for escape(). In fact, I don't see escape as being a property of the global object in ES4. Is it in the draft?
Garrett
-----Original Message----- From: Garrett Smith [mailto:dhtmlkitchen at gmail.com] Sent: 25. mars 2008 08:43 To: Erik Arvidsson Cc: Lars Hansen; es4-discuss at mozilla.org Subject: Re: ES4 draft: the global object
WRT escape, that has seen much less use lately. All the libraries are using encodeURIComponent and they don't even have a fallback for escape(). In fact, I don't see escape as being a property of the global object in ES4. Is it in the draft?
It's in Appendix B in E262-3 and I expect it will remain there in E262-4. With Date.prototype.getYear and all the other ones we know and love.
-----Original Message----- From: zeppieri at gmail.com [mailto:zeppieri at gmail.com] On Behalf Of Jon Zeppieri Sent: 25. mars 2008 06:47 To: Lars Hansen Cc: es4-discuss at mozilla.org Subject: Re: ES4 draft: the global object
2008/3/24 Lars Hansen <lhansen at adobe.com>:
I would in particular like comments on eval.
Why does the operator form of eval have the name 'intrinsic::eval' (in addition to plain 'eval')? Either eval has the distinction of being the only namespaced operator in the language, or else this is a pun.
Neither :-)
Either way, I don't see the justification. Backwards compatibility can't be the issue, since ES3 doesn't have namespaces.
It's a usability argument.
At the moment there are two global bindings for eval: the name we can write as null::eval (eval in no namespace, ie, the same name ES3 programs know it by) and intrinsic::eval. These two programs always mean the same thing [*]:
intrinsic::eval(s)
and
{ use namespace intrinsic; eval(s); }
However it seems to me -- and I'm sure this is what we should be discussion -- that the latter use of eval is most likely intended to be the same as this program:
eval(s)
But then the first program also means the same thing as the third program.
Note also that
eval(s)
is the same as
null::eval(s)
so arguments about 'namespaced operators' are probably not right.
IMO the operator form of eval should be outlawed in all ES4 code (ie, it should be more restrictive than what's currently written up) but that's a discussion for another thread, maybe.
--lars
[*] User code can't introduce 'intrinsic' bindings except as overrides. There is no predefined method called 'eval' except the global function. Ergo the only code that can shadow 'eval' uses 'with (g) ' where g is a global object. But then the two programs still mean the same thing, namely g.intrinsic::eval(s).
I think I need to understand the following before I can comprehend the rest:
On Tue, Mar 25, 2008 at 12:42 PM, Lars Hansen <lhansen at adobe.com> wrote:
Note also that
eval(s)
is the same as
null::eval(s)
so arguments about 'namespaced operators' are probably not right.
Not right in what sense? I'm not sure whether you're claiming that the operator form of intrinsic::eval isn't a namespaced operator (in which case, how is it not a pun?) or that it's not the only namespaced operator. (Or maybe you mean something else entirely...)
Is the following legal ES4:
(x null::< y)
(I would have thought no.)
Do operator identifiers (like '<') name syntactic bindings? Or maybe the term 'operator' is being used equivocally here?
-----Original Message----- From: zeppieri at gmail.com [mailto:zeppieri at gmail.com] On Behalf Of Jon Zeppieri Sent: 25. mars 2008 10:30 To: Lars Hansen Cc: es4-discuss at mozilla.org Subject: Re: ES4 draft: the global object
I think I need to understand the following before I can comprehend the rest:
On Tue, Mar 25, 2008 at 12:42 PM, Lars Hansen <lhansen at adobe.com> wrote:
Note also that
eval(s)
is the same as
null::eval(s)
so arguments about 'namespaced operators' are probably not right.
Not right in what sense? I'm not sure whether you're claiming that the operator form of intrinsic::eval isn't a namespaced operator (in which case, how is it not a pun?) or that it's not the only namespaced operator. (Or maybe you mean something else entirely...)
I mean that all names are in some namespace, and the name you think of as "isNaN" is really "null::isNaN", where null represents a "compatibility namespace", to pick something less ambiguous than "eval".
Is the following legal ES4:
(x null::< y)
(I would have thought no.)
Not at present, and not previously.
Do operator identifiers (like '<') name syntactic bindings?
No.
Or maybe the term 'operator' is being used equivocally here?
Operator in the sense that '<' is syntax that causes the language implementation to operated upon values, but there is no operator overloading and no syntactic bindings for operators at present. (They were in for a while, and operators were in the intrinsic namespace: intrinsic::=== for example.)
On Tue, Mar 25, 2008 at 5:47 PM, Lars Hansen <lhansen at adobe.com> wrote:
Not right in what sense? I'm not sure whether you're claiming that the operator form of intrinsic::eval isn't a namespaced operator (in which case, how is it not a pun?) or that it's not the only namespaced operator. (Or maybe you mean something else entirely...)
I mean that all names are in some namespace, and the name you think of as "isNaN" is really "null::isNaN", where null represents a "compatibility namespace", to pick something less ambiguous than "eval".
All names are in some namespace, yes, but not every identifier (using the term somewhat loosely) is a name. 'eval' can be a name (i.e., it can name a function that performs evaluation, or it can name some other value if it is re-bound), but qua operator I don't see how it could be a name -- unless it's unique among operators. And if it is unique in this respect, is the benefit worth the inconsistency?
Do operator identifiers (like '<') name syntactic bindings?
No.
But 'eval' does/can?
Or maybe the term 'operator' is being used equivocally here?
Operator in the sense that '<' is syntax that causes the language implementation to operated upon values, but there is no operator overloading and no syntactic bindings for operators at present. (They were in for a while, and operators were in the intrinsic namespace: intrinsic::=== for example.)
But it sounds to me like the intrinsic::eval operator depends upon the notion that operators have syntactic bindings. Otherwise, I don't see what sense it makes to refer to an operator's name. And if that doesn't make sense, then neither does referring to an operator's namespace.
My comments on this chapter:
The "operator form of eval" is used before it's described, which confused me while reading this document.
It bothers me that the eval operator form and the eval function form produce different valid results for the same input. If we provide both and both are called "eval", then the latter must be a subset of the former.
Waldemar
Enclosing Draft 1 of the global object spec. Quite a few changes here from ES3, and I've included a large expository section on eval that may not be appropriate for the final spec but which is probably useful right now, since it's the first attempt at a unified spec for all the eval changes that have been proposed.
Probably a few rough edges here, but more than enough to start looking at.