New private names proposal
dherman at mozilla.com
Thu Dec 23 00:14:19 PST 2010
[having trouble with my phone. Trying again]
This doesn't have anything to do with new revisions of the names proposal. Every version, including the original, extended [[Get]] and [[Set]] and hence effectively overloaded the square bracket notation.
----- Original Message -----
From: Mark S. Miller <erights at google.com>
To: Dave Herman <dherman at mozilla.com>
Cc: David-Sarah Hopwood <david-sarah at jacaranda.org>, es-discuss at mozilla.org
Sent: Wed, 22 Dec 2010 23:56:46 -0800 (PST)
Subject: Re: New private names proposal
On Wed, Dec 22, 2010 at 11:30 PM, Dave Herman <dherman at mozilla.com> wrote:
> MarkM's desugaring doesn't look correct to me at all. Given that names can
> always be looked up in objects, regardless of whether they are bound with
> 'private', it is not amenable to simulation via local desugaring. You'd have
> to change the way square brackets are treated universally. Did you see my
> message about this earlier in the thread?
I agree. I have not revisited the  issue specifically in light of the new
names syntax except for the section where I refer to the previous 
discussion as a kludge. (Just noting again that my "kludge" admission there
predates this thread.) Depending on what pair of syntax and semantics we
desire, if we do want to use  with soft fields, then I agree -- you cannot
do so by desugaring. Instead, I would change the [[Get]] and [[Put]]
operations to test if their argument is a SoftField, in a precisely
analogous to how Names would change these to check whether the argument is a
Name. This would make SoftFields necessarily built-in rather than equivalent
to a library, just as Names are. I consider this a demerit but not fatal --
I prefer proposals that can be explained as equivalent to a library. YMMV.
Nevertheless, if we decide this use with square brackets is important, I
would not object to making this change to [[Get]] and [[Put]].
My current preference is that, rather than extend the use of  for either
proposal, that we adopt some alternate syntax, such as sigils or @, that
preserves the analogy with public properties but maintains a distinction
between the two. This is not a deeply held or thought through position. I
look forward to an exploration of possible syntaxes. As several have
suggested, both publicly and privately (thanks), I no longer recuse myself
from syntax. But I will strive to keep these discussions separate until
someone shows a compelling coupling between the two.
More information about the es-discuss