Discuss
  • DRAFT: Names spec

DRAFT: Names spec

# Jeff Dyer (17 years ago)

Please find attached a draft spec that describes how names are structured and resolved in ES4. This is the first of several fundamental sections on the core language. As such it might seem lacking for context. At this early stage of review please use your imagination as much as possible to fill in the gaps. Drafts on syntax, types, values, and execution will be forthcoming in the next few weeks. These will help to complete a "bootable" image of the core language spec.

Thanks in advance for any an all feedback.

# Waldemar Horwat (17 years ago)

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
# Jeff Dyer (17 years ago)

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

# Waldemar Horwat (17 years ago)

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
# Mark S. Miller (17 years ago)

2008/4/6 Jeff Dyer <jodyer at adobe.com>:

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?

# Waldemar Horwat (17 years ago)

Mark S. Miller wrote:

2008/4/6 Jeff Dyer <jodyer at adobe.com <mailto:jodyer at adobe.com>>:

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