Re: DRAFT: Names spec

[Waldemar Horwat]

Mark S. Miller wrote:
> 2008/4/6 Jeff Dyer <[EMAIL PROTECTED] >:
>  
> 
> Every unforgeable namespace is considered non-equal to every other
> namespace.
> 
> *Implementation*
> 
> fun compareNamespaces (n1: NAMESPACE, n2: NAMESPACE) : bool =
> case (n1, n2) of
> (ForgeableNamespace s1, ForgeableNamespace s2) => s1 = s2
> | _ => false
> 
> In ES3, NaN is the only value that isn't reflexive, i.e., for which x != 
> x or x !== x. Does this spec propose that unforgeable namespaces are 
> also non-reflexive?

I pointed out the same thing.  I'm pretty sure that's a bug in the document.

Waldemar
___
Es4-discuss mailing list
Es4-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es4-discuss

Re: DRAFT: Names spec

[Mark S. Miller]

2008/4/6 Jeff Dyer <[EMAIL PROTECTED]>:


> Every unforgeable namespace is considered non-equal to every other
> namespace.
>
> *Implementation*
>
> fun compareNamespaces (n1: NAMESPACE, n2: NAMESPACE) : bool =
case (n1, n2) of
(ForgeableNamespace s1, ForgeableNamespace s2) => s1 = s2
| _ => false

In ES3, NaN is the only value that isn't reflexive, i.e., for which x != x
or x !== x. Does this spec propose that unforgeable namespaces are also
non-reflexive?

-- 
Cheers,
--MarkM
___
Es4-discuss mailing list
Es4-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es4-discuss

Re: DRAFT: Names spec

[Waldemar Horwat]

Jeff Dyer wrote:
> Thanks for the notes. I'm drafting an update based on comments from Lars and
> Graydon, so additional fixes are coming.

I went through the rest of the document.  The concepts look good so far.

Waldemar
___
Es4-discuss mailing list
Es4-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es4-discuss

Re: DRAFT: Names spec

[Jeff Dyer]

Thanks for the notes. I'm drafting an update based on comments from Lars and
Graydon, so additional fixes are coming.

Jd


On 4/15/08 5:58 PM, Waldemar Horwat wrote:

> My comments on 1.1:
> 
> fun compareNamespaces (n1: NAMESPACE, n2: NAMESPACE) : bool =
> case (n1, n2) of
> (ForgeableNamespace s1, ForgeableNamespace s2) => s1 = s2
>   | _ => false
> 
> An unforgeable namespace is not equal to itself???
> 
> (As an expository note, I don't like the name "compareFoo".  If "compareFoo(x,
> y)" returns true, what does that mean?  Does it mean that x < y?  x == y?
> Something else?  I'd prefer a name like "fooEqual".)
> 
> 
> Compatibility Namespace:
> 
> The section argues that the compatibility namespace can't be the public
> namespace, but the example given doesn't support that conclusion:
> 
> namespace N
> var o = {x: 10, N::x: 20}
> print (o.x)  // prints 10
> 
> {
> use namespace N
> print (o.x)   // ambiguous
> print (o.public::x)  // prints 10
> print (o.N::x)  // prints 20
> }
> 
> Here the "x" in "o.x" could be in any open namespace until the namespace
> resolution process is done.  It may or may not happen to be in the
> compatibility namespace.  I don't see why the compatibility namespace can't be
> the public namespace and, barring strong evidence to the contrary, think that
> they should be the same namespace.  It's too confusing not to do that, as then
> you'd have three different values for the "null" namespace.
> 
> I wouldn't worry about polishing "with".  It shouldn't be a priority.
> 
> 
> I'll review more of this tomorrow.
> 
> Waldemar
> 

___
Es4-discuss mailing list
Es4-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es4-discuss

Re: DRAFT: Names spec

[Waldemar Horwat]

My comments on 1.1:

fun compareNamespaces (n1: NAMESPACE, n2: NAMESPACE) : bool =
case (n1, n2) of
(ForgeableNamespace s1, ForgeableNamespace s2) => s1 = s2
  | _ => false

An unforgeable namespace is not equal to itself???

(As an expository note, I don't like the name "compareFoo".  If "compareFoo(x, 
y)" returns true, what does that mean?  Does it mean that x < y?  x == y?  
Something else?  I'd prefer a name like "fooEqual".)


Compatibility Namespace:

The section argues that the compatibility namespace can't be the public 
namespace, but the example given doesn't support that conclusion:

namespace N
var o = {x: 10, N::x: 20}
print (o.x)  // prints 10

{
use namespace N
print (o.x)   // ambiguous
print (o.public::x)  // prints 10
print (o.N::x)  // prints 20
}

Here the "x" in "o.x" could be in any open namespace until the namespace 
resolution process is done.  It may or may not happen to be in the 
compatibility namespace.  I don't see why the compatibility namespace can't be 
the public namespace and, barring strong evidence to the contrary, think that 
they should be the same namespace.  It's too confusing not to do that, as then 
you'd have three different values for the "null" namespace.

I wouldn't worry about polishing "with".  It shouldn't be a priority.


I'll review more of this tomorrow.

Waldemar

___
Es4-discuss mailing list
Es4-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es4-discuss