ES4 draft: Name

classic Classic list List threaded Threaded
29 messages Options
12
Reply | Threaded
Open this post in threaded view
|

ES4 draft: Name

Lars Hansen-3
Name objects represent reflected namespace::identifier pairs.  Here's
the draft spec.

Comments welcome.

--lars

_______________________________________________
Es4-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es4-discuss

Name.html (10K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: ES4 draft: Name

Yuh-Ruey Chen
Lars Hansen wrote:

Name (a, b=…)

Description

The Name class object called as a function creates a new Name object by passing its arguments a and b to the Name constructor.

Returns

The Name class object called as a function returns a Name object.

Implementation

static meta function invoke(a, b=undefined): Name
    new Name(a, b);
  

If a is already a Name, shouldn't Name(a) simply return a? Not sure what the policy on this is, but if you've changed Map to work similarly, then I don't see why not here as well.

-Yuh-Ruey Chen

_______________________________________________
Es4-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es4-discuss
Reply | Threaded
Open this post in threaded view
|

RE: ES4 draft: Name

Lars Hansen-3
It depends on whether we care about object identity or not for immutable objects like Name that don't have special support from the language (eg in comparison operators).  Useful question, though.  I will ponder it.
 
--lars


From: Yuh-Ruey Chen [mailto:[hidden email]]
Sent: 5. mars 2008 21:55
To: Lars Hansen
Cc: [hidden email]
Subject: Re: ES4 draft: Name

Lars Hansen wrote:

Name (a, b=…)

Description

The Name class object called as a function creates a new Name object by passing its arguments a and b to the Name constructor.

Returns

The Name class object called as a function returns a Name object.

Implementation

static meta function invoke(a, b=undefined): Name
    new Name(a, b);
  

If a is already a Name, shouldn't Name(a) simply return a? Not sure what the policy on this is, but if you've changed Map to work similarly, then I don't see why not here as well.

-Yuh-Ruey Chen

_______________________________________________
Es4-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es4-discuss
Reply | Threaded
Open this post in threaded view
|

RE: ES4 draft: Name

Lars Hansen-3
In reply to this post by Lars Hansen-3
Draft 2, changelog near the beginning.

Please note the OPEN ISSUES section, which names two fairly
arbitrary designs in this proposal.  Comments welcome.

--lars

> -----Original Message-----
> From: [hidden email]
> [mailto:[hidden email]] On Behalf Of Lars Hansen
> Sent: 5. mars 2008 17:32
> To: [hidden email]
> Subject: ES4 draft: Name
>
> Name objects represent reflected namespace::identifier pairs.
>  Here's the draft spec.
>
> Comments welcome.
>
> --lars
>

_______________________________________________
Es4-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es4-discuss

Name.html (12K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: ES4 draft: Name

Waldemar Horwat
> public function Name(a, b=undefined)
> static meta function invoke(a, b=undefined): Name

It would be help the spec's readability if the formal parameters had more descriptive names than "a" and "b".  Here it's not clear which one is which.


> new Name( a, b=... )

Ah, I see why the formal parameters were called "a" and "b".  I think that the design is too weird though -- one of the parameters ought to be a name and the other one ought to be an optional namespace.  If I have the following:

var ns:Namespace = ...
var id:string = ...

and don't know anything about the ...'s, then I currently can't just call:

  n = new Name(ns, id);

Instead, I must use:

  if (ns !== null)
    n = new Name(ns, id);
  else
    n = new Name(id, undefined);

The reason is that, under the current specification, new Name(null, x) requires x to be undefined (null is a Name).

[I'm assuming that the expression
  null is T
is true for any nullable type T.  If that's not the case, then there are different issues here.]


My preference would be to always have the identifier as the first parameter and the namespace as the optional second parameter.  This will avoid hassles with values like null that can be either a namespace or a name.


Is there a compelling reason to treat numbers between 0 and 2^32-1 specially here?  It adds complexity and I'm not sure what it's for.


Creating the ambiguity of whether Name values appear to be interned is likely to lead to trouble.  For example, if I create a Map<Name, ...> and insert the result of
  Name(ns, "abc")
into it then it's unclear whether the value
  Name(ns, "abc")
will be present in the map.  It's at the implementation's whim.  We should specify it one way or another; my preference is to make these indistinguishable, which can be done either by interning them when creating them or by making === not distinguish them.


> The |Name| constructor is implementation-dependent.

What implementation-dependent behavior does it have, other than the above?  Shouldn't it be normatively specified in the spec?

What is analyzeArgs?  It's defined but not used here.


Why does valueOf do a toString on the Name?


    Waldemar
_______________________________________________
Es4-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es4-discuss
Reply | Threaded
Open this post in threaded view
|

Re: ES4 draft: Name

Igor Bukanov-2
The two-arguments Name constructor follow E4X where the corresponding
constructor for QName has the form:

QName(namespace, id)

Regards, Igor

On 12/03/2008, Waldemar Horwat <[hidden email]> wrote:

> > public function Name(a, b=undefined)
>
> > static meta function invoke(a, b=undefined): Name
>
>
> It would be help the spec's readability if the formal parameters had more descriptive names than "a" and "b".  Here it's not clear which one is which.
>
>
>  > new Name( a, b=... )
>
>  Ah, I see why the formal parameters were called "a" and "b".  I think that the design is too weird though -- one of the parameters ought to be a name and the other one ought to be an optional namespace.  If I have the following:
>
>  var ns:Namespace = ...
>  var id:string = ...
>
>  and don't know anything about the ...'s, then I currently can't just call:
>
>   n = new Name(ns, id);
>
>  Instead, I must use:
>
>   if (ns !== null)
>     n = new Name(ns, id);
>   else
>     n = new Name(id, undefined);
>
>  The reason is that, under the current specification, new Name(null, x) requires x to be undefined (null is a Name).
>
>  [I'm assuming that the expression
>   null is T
>  is true for any nullable type T.  If that's not the case, then there are different issues here.]
>
>
>  My preference would be to always have the identifier as the first parameter and the namespace as the optional second parameter.  This will avoid hassles with values like null that can be either a namespace or a name.
>
>
>  Is there a compelling reason to treat numbers between 0 and 2^32-1 specially here?  It adds complexity and I'm not sure what it's for.
>
>
>  Creating the ambiguity of whether Name values appear to be interned is likely to lead to trouble.  For example, if I create a Map<Name, ...> and insert the result of
>   Name(ns, "abc")
>  into it then it's unclear whether the value
>   Name(ns, "abc")
>  will be present in the map.  It's at the implementation's whim.  We should specify it one way or another; my preference is to make these indistinguishable, which can be done either by interning them when creating them or by making === not distinguish them.
>
>
>  > The |Name| constructor is implementation-dependent.
>
>  What implementation-dependent behavior does it have, other than the above?  Shouldn't it be normatively specified in the spec?
>
>  What is analyzeArgs?  It's defined but not used here.
>
>
>  Why does valueOf do a toString on the Name?
>
>
>     Waldemar
>  _______________________________________________
>  Es4-discuss mailing list
>  [hidden email]
>  https://mail.mozilla.org/listinfo/es4-discuss
>
_______________________________________________
Es4-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es4-discuss
Reply | Threaded
Open this post in threaded view
|

==, ===, and Name/Namspace (was: RE: ES4 draft: Name)

Lars Hansen-3
In reply to this post by Waldemar Horwat
(Partial followup to address one point and open a debate on it.)

> -----Original Message-----
> From: Waldemar Horwat [mailto:[hidden email]]
> Sent: 11. mars 2008 19:17
> To: Lars Hansen
> Cc: [hidden email]
> Subject: Re: ES4 draft: Name
>
> Creating the ambiguity of whether Name values appear to be
> interned is likely to lead to trouble.  

Agreed, this is not-good design.  Ditto for Namespace, to the
extent it has the same problem.

> For example, if I create a Map<Name, ...> and insert the result of
>
>   Name(ns, "abc")
>
> into it then it's unclear whether the value
>
>   Name(ns, "abc")
>
> will be present in the map.  It's at the implementation's
> whim.  We should specify it one way or another; my preference
> is to make these indistinguishable, which can be done either
> by interning them when creating them or by making === not
> distinguish them.

I agree.  All sealed "value types" in ES3 (primitive strings,
numbers, booleans) are indistinguishable to ===; Name and
Namespace are new value types in ES4 and should get the same
treatment.

However --

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 Name).
But in Firefox, Namespace is dynamic (not so in ActionScript) so
== but not === makes sense; if Namespace is not dynamic in ES4
we can get away with the changed behavior.  Still, might pose
a backward compatibility risk.  On the third hand, E4X is not
used on the web in general, only in apps targeted to FF and AS3.

"Name" is new in ES4 and we can do what we want.

Brendan, Igor, Jeff -- opinions about possible compatibility
issues with Namespace from E4X, given that we would want to
keep Namespace in ES4 immutable so that === makes sense?

(Presumably hash-consing is incompatible with current
behavior too.)

--lars
_______________________________________________
Es4-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es4-discuss
Reply | Threaded
Open this post in threaded view
|

Re: ==, ===, and Name/Namspace (was: RE: ES4 draft: Name)

Brendan Eich-2
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 Name).

All per ECMA-357, the E4X spec.

> But in Firefox, Namespace is dynamic (not so in ActionScript) so
> == but not === makes sense; if Namespace is not dynamic in ES4
> we can get away with the changed behavior.  Still, might pose
> a backward compatibility risk.  On the third hand, E4X is not
> used on the web in general, only in apps targeted to FF and AS3.

This is a non-issue, AFAIK. See my earlier post on E4X.

No interoperable web content uses E4X, and the Firefox-hosted E4X  
implementation could be versioned to support the old way, in the  
worst-case -- if there were significant Firefox-only content whose  
owners were unwilling or unable to upgrade their code.

I doubt that any such code exists, but the approach I would favor,  
given an incompatible but better ES4 spec, would be to try to break  
support for such code early during a major Mozilla milestone cycle,  
to smoke out any customers and then persuade them to revise their to  
satisfy ES4's rules.

I know of no E4X code that depends on current identity and mutability  
rules. Zwetan (for AS3), Jeff Walden, and others may have thoughts,  
so thanks for posting this to the list.

/be
_______________________________________________
Es4-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es4-discuss
Reply | Threaded
Open this post in threaded view
|

RE: ES4 draft: Name

Lars Hansen-3
In reply to this post by Waldemar Horwat
> -----Original Message-----
> From: Waldemar Horwat [mailto:[hidden email]]
> Sent: 11. mars 2008 19:17
> To: Lars Hansen
> Cc: [hidden email]
> Subject: Re: ES4 draft: Name
>
> > public function Name(a, b=undefined)
> > static meta function invoke(a, b=undefined): Name
>
> It would be help the spec's readability if the formal
> parameters had more descriptive names than "a" and "b".  Here
> it's not clear which one is which.
>
>
> > new Name( a, b=... )
>
> Ah, I see why the formal parameters were called "a" and "b".  
> I think that the design is too weird though -- one of the
> parameters ought to be a name and the other one ought to be
> an optional namespace.  If I have the following:
>
> var ns:Namespace = ...
> var id:string = ...
>
> and don't know anything about the ...'s, then I currently
> can't just call:
>
>   n = new Name(ns, id);
>
> Instead, I must use:
>
>   if (ns !== null)
>     n = new Name(ns, id);
>   else
>     n = new Name(id, undefined);
>
> The reason is that, under the current specification, new
> Name(null, x) requires x to be undefined (null is a Name).

Maybe that would be the better bug to fix -- allowing null
explicitly as a namespace to cover that case.

> [I'm assuming that the expression
>   null is T
> is true for any nullable type T.  If that's not the case,
> then there are different issues here.]

That is the case.

> My preference would be to always have the identifier as the
> first parameter and the namespace as the optional second
> parameter.  This will avoid hassles with values like null
> that can be either a namespace or a name.

As Igor pointed out that is incompatible with E4X, but that's
hardly a good reason.

(What we could be looking at here is an artifact of specifying
the language entirely with ES code, which is too weak to
express the idea of multiple interfaces to a function.)

I think it's desirable to keep the current order for compatibility
with existing designs (it's not like E4X sees no use).  I'll
try to clean up the constructor interface to be more robust /
friendly.

> Is there a compelling reason to treat numbers between 0 and
> 2^32-1 specially here?  It adds complexity and I'm not sure
> what it's for.

It's because of EnumerableId, which treats values in that range
specially.  The thought behind the code the way it's written is
that if one wishes to construct a Name, then the parameters
must conform to those of EnumerableId: Name, string, or uint.
Otherwise there's a type error.

However, this is a little too hard-nosed, and EnumerableId
is changing anyway (if int and uint go away, as I expect they
will), so I'll probably remove the checking here, and just
add conversion to string for any argument at all.

> Creating the ambiguity of whether Name values appear to be
> interned is likely to lead to trouble.  

Yes.  See separate thread that I spun off this one.

> > The |Name| constructor is implementation-dependent.
>
> What implementation-dependent behavior does it have, other
> than the above?  Shouldn't it be normatively specified in
> the spec?

It's implementation-defined whether the result of this is true:

  x = new Name(a,b)
  y = new Name(a,b)
  x === y

but as discussed in that other thread, that problem needs to be
solved, so the problem with "implementation-defined" here should
go away.

> What is analyzeArgs?  It's defined but not used here.

"The helper function analyzeArgs, called by the Name constructor, takes
the two values a and b that were passed to the Name constructor and
returns an object containing a qualifier in the form of a namespace
(which may be null) and an identifier in the form of a string. The
qualifier and identifier are used to create the Name object."

> 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 the wiki); the
ActionScript implementation of the E4X "QName" valueOf method returns
'this'; that is probably the right behavior here as well.

--lars
_______________________________________________
Es4-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es4-discuss
Reply | Threaded
Open this post in threaded view
|

Re: ES4 draft: Name

Brendan Eich-2
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 the wiki);

The motivation there was to masquerade Name instances as strings to  
ES3 code that did

   for (var i in es4obj) {
     ... something assuming i is a string per ES3 here ...
   }

It was necessary to override valueOf and toString, since when this  
proposal was written we believed that for-in loops over objects with  
namespaced properties should iterate i over Name objects where  
necessary to distinguish such properties from those identified by  
names in no namespace.

We now are converging on hiding all namespaced properties from for-in  
enumeration, which is great. This change does not eliminate the need  
for Name objects in ES4, but it does mean that they may not need to  
masquerade as Strings via subtyping, for backward compatibility. So  
we should reconsider all the String hacks in Name.es in this light.

> the
> ActionScript implementation of the E4X "QName" valueOf method returns
> 'this'; that is probably the right behavior here as well.

E4X's QName prototype valueOf is not specified, so that method is  
delegated to Object.prototype.valueOf, which returns this.

/be

_______________________________________________
Es4-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es4-discuss
Reply | Threaded
Open this post in threaded view
|

RE: ES4 draft: Name

Lars Hansen-3
In reply to this post by Lars Hansen-3
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 spec that justifies these changes is
forthcoming.)

--lars

_______________________________________________
Es4-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es4-discuss

Name.html (10K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: ES4 draft: Name

Erik Arvidsson
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 <[hidden email]>:

> 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 spec that justifies these changes is
>  forthcoming.)
>
>  --lars
>
> _______________________________________________
>  Es4-discuss mailing list
>  [hidden email]
>  https://mail.mozilla.org/listinfo/es4-discuss
>
>



--
erik
_______________________________________________
Es4-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es4-discuss
Reply | Threaded
Open this post in threaded view
|

RE: ES4 draft: Name

Lars Hansen-3
I don't know if that's necessary; it follows directly from the
properties you mention and the fact that == and === work by
comparing the component fields.  (By analogy,
ES3 implementations already perform a fair amount of string
interning but I don't recall that being discussed in the ES3
spec.)

--lars

> -----Original Message-----
> From: Erik Arvidsson [mailto:[hidden email]]
> Sent: 17. mars 2008 17:28
> To: Lars Hansen
> Cc: [hidden email]
> Subject: Re: ES4 draft: Name
>
> 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 <[hidden email]>:
> > 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 spec that justifies these changes is
> >  forthcoming.)
> >
> >  --lars
> >
> > _______________________________________________
> >  Es4-discuss mailing list
> >  [hidden email]
> >  https://mail.mozilla.org/listinfo/es4-discuss
> >
> >
>
>
>
> --
> erik
>
_______________________________________________
Es4-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es4-discuss
Reply | Threaded
Open this post in threaded view
|

Re: ES4 draft: Name

Erik Arvidsson
Fair enough.  On a related question, does the following allow removal
of the field?

prototype function toString(this:Namespace)
    this.intrinsic::toString()

If not these should be changed to

prototype const function toString(this:Namespace)
    this.intrinsic::toString()

for Name and Namespace.

On Mon, Mar 17, 2008 at 17:06, Lars Hansen <[hidden email]> wrote:

> I don't know if that's necessary; it follows directly from the
>  properties you mention and the fact that == and === work by
>  comparing the component fields.  (By analogy,
>  ES3 implementations already perform a fair amount of string
>  interning but I don't recall that being discussed in the ES3
>  spec.)
>
>  --lars
>
>
>
>  > -----Original Message-----
>  > From: Erik Arvidsson [mailto:[hidden email]]
>  > Sent: 17. mars 2008 17:28
>  > To: Lars Hansen
>  > Cc: [hidden email]
>  > Subject: Re: ES4 draft: Name
>  >
>  > 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 <[hidden email]>:
>  > > 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 spec that justifies these changes is
>  > >  forthcoming.)
>  > >
>  > >  --lars
>  > >
>  > > _______________________________________________
>  > >  Es4-discuss mailing list
>  > >  [hidden email]
>  > >  https://mail.mozilla.org/listinfo/es4-discuss
>  > >
>  > >
>  >
>  >
>  >
>  > --
>  > erik
>  >
>



--
erik
_______________________________________________
Es4-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es4-discuss
Reply | Threaded
Open this post in threaded view
|

RE: ES4 draft: Name

Lars Hansen-3
Prototype properties are generally just DontEnum.  Why would
the toString prototype function need to be const for Name and
Namespace?

--lars

> -----Original Message-----
> From: Erik Arvidsson [mailto:[hidden email]]
> Sent: 17. mars 2008 18:09
> To: Lars Hansen
> Cc: [hidden email]
> Subject: Re: ES4 draft: Name
>
> Fair enough.  On a related question, does the following allow
> removal of the field?
>
> prototype function toString(this:Namespace)
>     this.intrinsic::toString()
>
> If not these should be changed to
>
> prototype const function toString(this:Namespace)
>     this.intrinsic::toString()
>
> for Name and Namespace.
>
> On Mon, Mar 17, 2008 at 17:06, Lars Hansen <[hidden email]> wrote:
> > I don't know if that's necessary; it follows directly from the  
> > properties you mention and the fact that == and === work by
>  comparing
> > the component fields.  (By analogy,
> >  ES3 implementations already perform a fair amount of string  
> > interning but I don't recall that being discussed in the ES3
> >  spec.)
> >
> >  --lars
> >
> >
> >
> >  > -----Original Message-----
> >  > From: Erik Arvidsson [mailto:[hidden email]]  
> > Sent: 17.
> > mars 2008 17:28  > To: Lars Hansen  > Cc:
> [hidden email]  >
> > Subject: Re: ES4 draft: Name  >  > 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 <[hidden email]>:
> >  > > 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 spec that
> justifies these
> > changes is  > >  forthcoming.)  > >  > >  --lars  > >  > >
> > _______________________________________________
> >  > >  Es4-discuss mailing list
> >  > >  [hidden email]
> >  > >  https://mail.mozilla.org/listinfo/es4-discuss
> >  > >
> >  > >
> >  >
> >  >
> >  >
> >  > --
> >  > erik
> >  >
> >
>
>
>
> --
> erik
>
_______________________________________________
Es4-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es4-discuss
Reply | Threaded
Open this post in threaded view
|

Re: ES4 draft: Name

Peter Hall-4
Perhaps, something like this:

var n1 = new Name("foo", "bar");
var n2 = new Name("foo", "bar");

n1.toString = function(){.....}

An implementation might have reasonably shared the same instance for
n1 and n2, but a user might be surprised that the new toString()
function is now found on what he considered to be two separate
instances.

Peter


On Tue, Mar 18, 2008 at 12:18 AM, Lars Hansen <[hidden email]> wrote:

> Prototype properties are generally just DontEnum.  Why would
>  the toString prototype function need to be const for Name and
>  Namespace?
>
>
>
>  --lars
>
>  > -----Original Message-----
>  > From: Erik Arvidsson [mailto:[hidden email]]
>  > Sent: 17. mars 2008 18:09
>  > To: Lars Hansen
>  > Cc: [hidden email]
>  > Subject: Re: ES4 draft: Name
>  >
>  > Fair enough.  On a related question, does the following allow
>  > removal of the field?
>  >
>  > prototype function toString(this:Namespace)
>  >     this.intrinsic::toString()
>  >
>  > If not these should be changed to
>  >
>  > prototype const function toString(this:Namespace)
>  >     this.intrinsic::toString()
>  >
>  > for Name and Namespace.
>  >
>  > On Mon, Mar 17, 2008 at 17:06, Lars Hansen <[hidden email]> wrote:
>  > > I don't know if that's necessary; it follows directly from the
>  > > properties you mention and the fact that == and === work by
>  >  comparing
>  > > the component fields.  (By analogy,
>  > >  ES3 implementations already perform a fair amount of string
>  > > interning but I don't recall that being discussed in the ES3
>  > >  spec.)
>  > >
>  > >  --lars
>  > >
>  > >
>  > >
>  > >  > -----Original Message-----
>  > >  > From: Erik Arvidsson [mailto:[hidden email]]
>  > > Sent: 17.
>  > > mars 2008 17:28  > To: Lars Hansen  > Cc:
>  > [hidden email]  >
>  > > Subject: Re: ES4 draft: Name  >  > 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 <[hidden email]>:
>  > >  > > 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 spec that
>  > justifies these
>  > > changes is  > >  forthcoming.)  > >  > >  --lars  > >  > >
>  > > _______________________________________________
>  > >  > >  Es4-discuss mailing list
>  > >  > >  [hidden email]
>  > >  > >  https://mail.mozilla.org/listinfo/es4-discuss
>  > >  > >
>  > >  > >
>  > >  >
>  > >  >
>  > >  >
>  > >  > --
>  > >  > erik
>  > >  >
>  > >
>  >
>  >
>  >
>  > --
>  > erik
>  >
>  _______________________________________________
>  Es4-discuss mailing list
>  [hidden email]
>  https://mail.mozilla.org/listinfo/es4-discuss
>
_______________________________________________
Es4-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es4-discuss
Reply | Threaded
Open this post in threaded view
|

RE: ES4 draft: Name

Lars Hansen-3
That won't work; n1 and n2 are final and non-dynamic.  And the prototype
property is on the prototype, so you'd have to go

Name.prototype.toString = function () ...

but then you know what you're doing, hopefully.

--lars

> -----Original Message-----
> From: [hidden email] [mailto:[hidden email]] On
> Behalf Of Peter Hall
> Sent: 17. mars 2008 18:25
> To: Lars Hansen
> Cc: Erik Arvidsson; [hidden email]
> Subject: Re: ES4 draft: Name
>
> Perhaps, something like this:
>
> var n1 = new Name("foo", "bar");
> var n2 = new Name("foo", "bar");
>
> n1.toString = function(){.....}
>
> An implementation might have reasonably shared the same instance for
> n1 and n2, but a user might be surprised that the new
> toString() function is now found on what he considered to be
> two separate instances.
>
> Peter
>
>
> On Tue, Mar 18, 2008 at 12:18 AM, Lars Hansen
> <[hidden email]> wrote:
> > Prototype properties are generally just DontEnum.  Why would  the
> > toString prototype function need to be const for Name and  
> Namespace?
> >
> >
> >
> >  --lars
> >
> >  > -----Original Message-----
> >  > From: Erik Arvidsson [mailto:[hidden email]]  
> > Sent: 17.
> > mars 2008 18:09  > To: Lars Hansen  > Cc:
> [hidden email]  >
> > Subject: Re: ES4 draft: Name  >  > Fair enough.  On a related
> > question, does the following allow  > removal of the field?
> >  >
> >  > prototype function toString(this:Namespace)
> >  >     this.intrinsic::toString()
> >  >
> >  > If not these should be changed to
> >  >
> >  > prototype const function toString(this:Namespace)
> >  >     this.intrinsic::toString()
> >  >
> >  > for Name and Namespace.
> >  >
> >  > On Mon, Mar 17, 2008 at 17:06, Lars Hansen
> <[hidden email]> wrote:
> >  > > I don't know if that's necessary; it follows directly
> from the  >
> > > properties you mention and the fact that == and === work by  >  
> > comparing  > > the component fields.  (By analogy,  > >  ES3
> > implementations already perform a fair amount of string  >
> > interning
> > but I don't recall that being discussed in the ES3  > >  
> spec.)  > >  
> > > >  --lars  > >  > >  > >  > >  > -----Original
> Message-----  > >  >
> > From: Erik Arvidsson [mailto:[hidden email]]  > >
> Sent: 17.
> >  > > mars 2008 17:28  > To: Lars Hansen  > Cc:
> >  > [hidden email]  >
> >  > > Subject: Re: ES4 draft: Name  >  > 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 <[hidden email]>:
> >  > >  > > 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
> > spec that  > justifies these  > > changes is  > >  
> forthcoming.)  > >  
> > > >  --lars  > >  > >  > >
> > _______________________________________________
> >  > >  > >  Es4-discuss mailing list
> >  > >  > >  [hidden email]
> >  > >  > >  https://mail.mozilla.org/listinfo/es4-discuss
> >  > >  > >
> >  > >  > >
> >  > >  >
> >  > >  >
> >  > >  >
> >  > >  > --
> >  > >  > erik
> >  > >  >
> >  > >
> >  >
> >  >
> >  >
> >  > --
> >  > erik
> >  >
> >  _______________________________________________
> >  Es4-discuss mailing list
> >  [hidden email]
> >  https://mail.mozilla.org/listinfo/es4-discuss
> >
>
_______________________________________________
Es4-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es4-discuss
Reply | Threaded
Open this post in threaded view
|

RE: ES4 draft: Name

Lars Hansen-3
In reply to this post by Lars Hansen-3
Last call for comments.

--lars

_______________________________________________
Es4-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es4-discuss

Name.html (11K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: ES4 draft: Name

Mark S. Miller-2
2008/3/20 Lars Hansen <[hidden email]>:
> Last call for comments.

Since you're asking for a last call, I'll go on record as objecting to
the introduction of Names, Namespaces, packages, and units. I think
the current JavaScript practice --- of using lexical scoping, objects
as records, package naming paths as dotted paths through records
(e.g., Dojo & YUI) --- addresses most of these needs by patterns
expressed using more basic primitives. If these new concepts were
merely conveniences that could be explained as supporting and
abstracting such patterns, as various Scheme module systems have done,
that would be much less of a problem. (Even then, such adventures
should not be designed in a standards committee.) However, as proposed
as new *primitive* concepts, these don't pull their weight. I also
object to classes on similar grounds, but we should probably keep that
discussion separate.

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 of at least three independent proposals for first-class
selector names that were intended to address it. At least one of these
were actually implemented. None were ever adopted by a significant
user community. The problem with all of these is that, by introducing
another layer of translation between the identifier the programmer
wrote and the thing that's looked up, you have to introduce and
explain all the mechanism for determining which translation to use in
what context. (The T variant of Scheme is the only example I know
where first-class selectors saw significant use. Though widely
admired, no other Scheme or Lisp variants picked up on this feature.)

As I understand the history, proposed ES4 Names and Namespaces came
from XML namespaces by way of the e4x adventure. However, there's a
big difference. XML fully qualified names are founded in string
identity (by comparing URLs). Their semantics can be explained by
expansion to mangled strings as names ("<url>:local-name"). Proposed
ES4 Names and Namespaces are founded in object identity. I don't like
XML-style names either. But mangled-strings-as-names don't present any
novel serialization problem beyond those of simple-strings-as-names.

--
 Cheers,
 --MarkM
_______________________________________________
Es4-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es4-discuss
Reply | Threaded
Open this post in threaded view
|

Re: ES4 draft: Name

Brendan Eich-2
On Mar 20, 2008, at 5:29 PM, Mark S. Miller wrote:

> As I understand the history, proposed ES4 Names and Namespaces came
> from XML namespaces by way of the e4x adventure.

Not so -- please see:

http://www.mozilla.org/js/language/old-js2/js20/core/namespaces.html

and talk to Waldemar Horwat about this long history.

/be
_______________________________________________
Es4-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es4-discuss
12