Re: ES4 draft: the global object
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 ___ Es4-discuss mailing list Es4-discuss@mozilla.org https://mail.mozilla.org/listinfo/es4-discuss
Re: ES4 draft: the global object
2008/3/24 Lars Hansen [EMAIL PROTECTED]: 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. -Jon ___ Es4-discuss mailing list Es4-discuss@mozilla.org https://mail.mozilla.org/listinfo/es4-discuss
Re: ES4 draft: the global object
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 [EMAIL PROTECTED]: 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. --lars ___ Es4-discuss mailing list Es4-discuss@mozilla.org https://mail.mozilla.org/listinfo/es4-discuss ___ Es4-discuss mailing list Es4-discuss@mozilla.org https://mail.mozilla.org/listinfo/es4-discuss
Re: ES4 draft: the global object
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 07:12, Garrett Smith [EMAIL PROTECTED] wrote: 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 [EMAIL PROTECTED]: 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. --lars ___ Es4-discuss mailing list Es4-discuss@mozilla.org https://mail.mozilla.org/listinfo/es4-discuss ___ Es4-discuss mailing list Es4-discuss@mozilla.org https://mail.mozilla.org/listinfo/es4-discuss -- erik ___ Es4-discuss mailing list Es4-discuss@mozilla.org https://mail.mozilla.org/listinfo/es4-discuss
Re: ES4 draft: the global object
On Tue, Mar 25, 2008 at 7:50 AM, Erik Arvidsson [EMAIL PROTECTED] 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 [EMAIL PROTECTED] wrote: snip -- erik ___ Es4-discuss mailing list Es4-discuss@mozilla.org https://mail.mozilla.org/listinfo/es4-discuss
Re: ES4 draft: the global object
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. -- erik ___ Es4-discuss mailing list Es4-discuss@mozilla.org https://mail.mozilla.org/listinfo/es4-discuss
Re: ES4 draft: the global object
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. /be ___ Es4-discuss mailing list Es4-discuss@mozilla.org https://mail.mozilla.org/listinfo/es4-discuss
Re: ES4 draft: the global object
On Tue, Mar 25, 2008 at 8:13 AM, Erik Arvidsson [EMAIL PROTECTED] 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 -- erik ___ Es4-discuss mailing list Es4-discuss@mozilla.org https://mail.mozilla.org/listinfo/es4-discuss
RE: ES4 draft: the global object
-Original Message- From: Garrett Smith [mailto:[EMAIL PROTECTED] Sent: 25. mars 2008 08:43 To: Erik Arvidsson Cc: Lars Hansen; es4-discuss@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. --lars ___ Es4-discuss mailing list Es4-discuss@mozilla.org https://mail.mozilla.org/listinfo/es4-discuss
RE: ES4 draft: the global object
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On
Behalf Of Jon Zeppieri
Sent: 25. mars 2008 06:47
To: Lars Hansen
Cc: es4-discuss@mozilla.org
Subject: Re: ES4 draft: the global object
2008/3/24 Lars Hansen [EMAIL PROTECTED]:
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).
___
Es4-discuss mailing list
Es4-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es4-discuss
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 [EMAIL PROTECTED] 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? ___ Es4-discuss mailing list Es4-discuss@mozilla.org https://mail.mozilla.org/listinfo/es4-discuss
RE: ES4 draft: the global object
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Jon Zeppieri Sent: 25. mars 2008 10:30 To: Lars Hansen Cc: es4-discuss@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 [EMAIL PROTECTED] 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.) --lars ___ Es4-discuss mailing list Es4-discuss@mozilla.org https://mail.mozilla.org/listinfo/es4-discuss
Re: ES4 draft: the global object
On Tue, Mar 25, 2008 at 5:47 PM, Lars Hansen [EMAIL PROTECTED] 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. -Jon --lars ___ Es4-discuss mailing list Es4-discuss@mozilla.org https://mail.mozilla.org/listinfo/es4-discuss
