On 2008-03-20, at 23:07 EDT, Lars Hansen wrote:
Names depend on object identity insofar as some namespace values
are equal only to themselves. I don't know how serialization is
a problem that figures into this, though clearly some namespaces
values can't be printed and then reconstituted in
-Original Message-
From: P T Withington [mailto:[EMAIL PROTECTED] On Behalf Of
P T Withington
Sent: 21. mars 2008 04:58
To: Lars Hansen
Cc: Mark S. Miller; es4-discuss@mozilla.org
Subject: Re: ES4 draft: Name
On 2008-03-20, at 23:07 EDT, Lars Hansen wrote:
Names depend
Mark S. Miller wrote:
The one use-case I can see for names and namespaces that isn't
addressed adequately by existing patterns is expanding the
property-name-space, to avoid accidental collisions on extensions to
common abstractions. I note that Smalltalk has long faced this issue,
and I know
-Original Message-
From: Mark S. Miller [mailto:[EMAIL PROTECTED]
Sent: 20. mars 2008 17:29
To: Lars Hansen
Cc: es4-discuss@mozilla.org
Subject: Re: ES4 draft: Name
2008/3/20 Lars Hansen [EMAIL PROTECTED]:
Last call for comments.
Since you're asking for a last call, I'll go
Draft 3 of the spec for the Name class. Changelog near the beginning.
The main change is that Name extends Object (not String) and that ===,
==, !==, and != operate not on object identity or on string
representation but directly on the (qualifier,identifier) pair. (A
draft of an enumerability
Should there be some informative text explaining that Names are
immutable (non dynamic, final and only constant fields) so interning
Name objects is something that might be useful for implementations?
2008/3/17 Lars Hansen [EMAIL PROTECTED]:
Draft 3 of the spec for the Name class. Changelog
.)
--lars
-Original Message-
From: Erik Arvidsson [mailto:[EMAIL PROTECTED]
Sent: 17. mars 2008 17:28
To: Lars Hansen
Cc: es4-discuss@mozilla.org
Subject: Re: ES4 draft: Name
Should there be some informative text explaining that Names
are immutable (non dynamic, final and only
of string
interning but I don't recall that being discussed in the ES3
spec.)
--lars
-Original Message-
From: Erik Arvidsson [mailto:[EMAIL PROTECTED]
Sent: 17. mars 2008 17:28
To: Lars Hansen
Cc: es4-discuss@mozilla.org
Subject: Re: ES4 draft: Name
Should
-
From: Erik Arvidsson [mailto:[EMAIL PROTECTED]
Sent: 17. mars 2008 18:09
To: Lars Hansen
Cc: es4-discuss@mozilla.org
Subject: Re: ES4 draft: Name
Fair enough. On a related question, does the following allow
removal of the field?
prototype function toString(this:Namespace
PROTECTED] On
Behalf Of Peter Hall
Sent: 17. mars 2008 18:25
To: Lars Hansen
Cc: Erik Arvidsson; es4-discuss@mozilla.org
Subject: Re: ES4 draft: Name
Perhaps, something like this:
var n1 = new Name(foo, bar);
var n2 = new Name(foo, bar);
n1.toString = function
On Mar 13, 2008, at 3:39 PM, Lars Hansen wrote:
Firefox currently has that new Namespace (for E4X) produces
a new object that is == to another namespace produced with the
same string but not ===. From looking at the code, ActionScript3
does the same thing. Ditto for names (QName in E4X, not
-Original Message-
From: Waldemar Horwat [mailto:[EMAIL PROTECTED]
Sent: 11. mars 2008 19:17
To: Lars Hansen
Cc: es4-discuss@mozilla.org
Subject: Re: ES4 draft: Name
public function Name(a, b=undefined)
static meta function invoke(a, b=undefined): Name
It would be help
On Mar 13, 2008, at 4:05 PM, Lars Hansen wrote:
Why does valueOf do a toString on the Name?
Entirely because the original spec (on the wiki) required it. I
suspect
this is the wrong design (and I think even Brendan, who wrote it up,
questioned it, because it's left as an open issue on
To: es4-discuss@mozilla.org
Subject: ES4 draft: Name
Name objects represent reflected namespace::identifier pairs.
Here's the draft spec.
Comments welcome.
--lars
Title: The class "Name"
The class Name
NAME: "The cla
14 matches
Mail list logo
