Re: New private names proposal
On 12/21/2010 11:58 PM, Brendan Eich wrote: I'm not keen on adding # as a sigil for private names, but this is mostly because such things are ugly, Perlish line noise. Under the explicit is better than implicit philosophy, and in particular the desire to eliminate even a static (compile-time only) parallel namespace, *maybe*. Ruby uses @, and while that still looks like Perl line noise, it doesn't in practice seem to get in the way all that much: there just aren't that many of them in most Ruby code, in my experience. (Part of that is because of Ruby's metaprogramming methods attr_reader and attr_accessor that define @ fields and corresponding getter and setter methods.) And speaking of Ruby and attr_reader, could the need for new syntax be reduced or eliminated with a sufficiently clever metaprogramming API? For example, and using an ungainly ES5-style function name: // Create and return a private name, and define a getter foo for it var name = Object.definePrivateProperty(o, foo); o.foo // = anyone can query the private property o[name] = new_value; // Setting the property requires the name object (I don't know how this would handle private fields in object literals, though) David ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: New private names proposal [repost]
On Dec 21, 2010, at 10:41 PM, David-Sarah Hopwood wrote:
Again you seem to be confusing the inherited soft fields proposal with
the *separate* proposal on desugaring the private name syntax to inherited
soft fields.
I think I may have been misunderstanding what Mark was actually
proposing/advocating, then. I'm happy to be disabused of my mis-reading.
But on re-reading, I still can't quite make sense of the Can we subsume
Names? section. There are two syntactic components to the private names
proposal:
(1) the bracket-notation is generalized to recognize private name values to
look for private properties
(2) the dot-notation and colon-notation are generalized to use private names
when their property name is bound by a |private| declaration
But the Can we subsume Names? subsection seems to mix these two cases up. To
match up with (1), you'd need to interpret *all* bracket notation as a
potential lookup of a soft field, i.e. something like:
e1[e2] ~~
let (t1 = e1, t2 = e2) {
= t2 instanceof SoftField
? t2.get(t1)
: t1[t2]
}
(where the rewritten brackets are the true brackets, i.e., not re-desugared).
Dave
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: New private names proposal
On 12/22/2010 01:02 AM, David Herman wrote:
In order for this to work you have to abandon the idea of scoped private
identifiers. I say: make all private identifiers scoped to the compilation
unit.
This is the part of your suggestion that I don't like: it makes private identifiers too blunt a tool.You end up sharing with more code than you want, and when you refactor
by pulling code out of one compilation unit and into another, you share
less than you want. Lexical scope is a tried-and-true mechanism for
controlling sharing, and it works better than compilation units.
Moreover, we don't even have a clear notion of compilation unit in the
language.
It is blunt, and I'm not thrilled with it. But it might satisfy the most
common use cases without preventing authors from using private names
manually when more control is required...
But your idea suggests yet another alternative worth adding to our growing
pantheon. We could allow for the scoping of private names, but always require
them to be prefixed by the sigil. This way there's no possibility of mixing up
public and private names. So to use an earlier example from this thread
(originally suggested to me by Allen):
I do think that the conceptual clarity of requiring the sigil everywhere
might well outweigh the ugliness of the sigil.
function Point(x, y) {
private #x, #y;
this.#x = x;
this.#y = y;
}
I keep seeing this basic constructor example. But isn't this the case
that Oliver raised of private being over generative? Those private
names have been generated and discarded, and those two fields can never
be read again...
For your counter example, the original names proposal allowed for object
literals to declare private properties, and the private name was scoped to the
entire literal. So you'd write:
var counter = {
private #count: 0;
next: function() { return this.#count++; }
reset: function() { this.#count = 0; }
};
I like private as a keyword in object literals: it doesn't seem any more
confusing than get and set in literals. I don't like seeing it in
functions though: there it looks like a kind of var and const analog. I
suppose that allowing it only within object literals would eliminate too
many important use cases, however.
This is of course still strictly noisier than the original private names
proposal, but it does have the advantage of never capturing public names by
private declarations. It doesn't, however, address your concern about
generativity. Personally, I like the generativity; I think it matches up with
the use cases. But I acknowledge that it might be subtle.
Dave
Is there any syntax from the old ES4 namespace stuff that could be
applied here? Instead of declaring individual private identifers, could
we declare a private namespace identifier, and then use that namespace
identifier as a prefix for private properties within the namespace? No
sigil would be required then
At this point, I'm just thinking out loud, so I'll call it a night.
David
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: New private names proposal
On Dec 22, 2010, at 2:00 AM, David Flanagan wrote:
On 12/22/2010 01:02 AM, David Herman wrote:
function Point(x, y) {
private #x, #y;
this.#x = x;
this.#y = y;
}
I keep seeing this basic constructor example. But isn't this the case that
Oliver raised of private being over generative? Those private names have
been generated and discarded, and those two fields can never be read again...
Oops, I left out the ellipses:
function Point(x, y) {
private #x, #y;
this.#x = x;
this.#y = y;
...
}
Of course, if you wanted to extend the scope further, you could lift it out of
the constructor.
As for the complaint of it being over-generative, that's mitigated in this case
by the sigil. For example, if you wrote:
function Point(x, y) {
private #x, #y;
this.#x = x;
this.#y = y;
}
Point.prototype = {
... #x ... #y ...
};
you'd get a compile-time error since #x and #y aren't in scope. Unless, of
course, they are already in scope as another private, although I'd expect this
kind of thing to be a bit rarer than variable scope errors since I would guess
private names wouldn't be nested and repurposed as often as variables -- that's
just a guess; it's hard to be sure.
Also, you can only take the but if you do it wrong, it doesn't work arguments
so far. After all, the generativity is by design. The question is whether that
design will be too surprising and confusing. We shouldn't make JS too
complicated or baroque, but we shouldn't nix an idea based on assuming too
little of programmers. IOW, I think the too complicated criticism should be
used with competent programmers in mind.
Anyway, I'm also just thinking out loud. :)
I like private as a keyword in object literals: it doesn't seem any more
confusing than get and set in literals. I don't like seeing it in functions
though: there it looks like a kind of var and const analog.
Isn't this less the case when what follows the keyword isn't an ordinary
identifier, i.e., has the sigil?
Is there any syntax from the old ES4 namespace stuff that could be applied
here?
An interesting thought, but I'm skeptical -- ES4 namespaces are pretty
dis-Harmonious, and for good reason: there be dragons. :)
Dave
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: New private names proposal
What about adding an attribute to properties that somehow
identify which classes (in the prototype chain for protected)
have access to the object? I'll leave the somehow up in the
air, but you could introduce a [[Private]] attribute which, if not
undefined, says which context must be set (and for protected,
either directly or through the prototypal chain of the current
context) to gain access to this property. And if that context is
not found, some error is thrown. Maybe it would be
[[EncapsulationType]] :: {private, protected, public} and
[[EncapsulationContext]] :: ?. You could also add a simple api
to check for these (isPrivate, isProtected, isPublic,
hasEncapsulatedProperty, etc) depending on how it would affect
in and enumeration.
I’m assuming (perhaps incorrectly) that this suggestion is to model the flag
of the private vs. non-private as a “property descriptor” that can be set by
`Object.defineProperty()`. Am I correct?
If so, I think that makes a lot of sense. I would like `private` to work
that way.
Of course, the setting of `private` would probably have to be one-way, like
`configurable` is, so that such a property could be made un-private by
another context.
BTW, pardon (and ignore) me if I just stepped on an ant-bed and confused the
whole topic. I’ve been following this thread silently and mostly felt like
it was much more complicated than I could understand. Peter’s post was the
first one that seemed to make sense. :)
--Kyle
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: New private names proposal
From my perspective as a JS programmer, overloading the dot seems confusing.
The gains in elegance don't appear to me to be worth it. However,
overloading [] might be more acceptable:
let x = new PrivateName();
// or perhaps:
private x;
function Point()
{
this[x] = 100;
}
function createPoint()
{
return {
[x]: 100,
};
}
function expando(obj)
{
obj[x] = 100; // OK even if object is not extensible
}
The extension of the object literal syntax to include [identifier] would be
a general nicety for me. There might be complications that I don't see, of
course. Thanks for letting me intrude!
Kevin
On Wed, Dec 22, 2010 at 10:27 AM, Kyle Simpson get...@gmail.com wrote:
What about adding an attribute to properties that somehow
identify which classes (in the prototype chain for protected)
have access to the object? I'll leave the somehow up in the
air, but you could introduce a [[Private]] attribute which, if not
undefined, says which context must be set (and for protected,
either directly or through the prototypal chain of the current
context) to gain access to this property. And if that context is
not found, some error is thrown. Maybe it would be
[[EncapsulationType]] :: {private, protected, public} and
[[EncapsulationContext]] :: ?. You could also add a simple api
to check for these (isPrivate, isProtected, isPublic,
hasEncapsulatedProperty, etc) depending on how it would affect
in and enumeration.
I’m assuming (perhaps incorrectly) that this suggestion is to model the
flag of the private vs. non-private as a “property descriptor” that can be
set by `Object.defineProperty()`. Am I correct?
If so, I think that makes a lot of sense. I would like `private` to work
that way.
Of course, the setting of `private` would probably have to be one-way, like
`configurable` is, so that such a property could be made un-private by
another context.
BTW, pardon (and ignore) me if I just stepped on an ant-bed and confused
the whole topic. I’ve been following this thread silently and mostly felt
like it was much more complicated than I could understand. Peter’s post was
the first one that seemed to make sense. :)
--Kyle
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: New private names proposal
On Dec 22, 2010, at 6:26 AM, David Herman wrote:
On Dec 22, 2010, at 2:00 AM, David Flanagan wrote:
On 12/22/2010 01:02 AM, David Herman wrote:
function Point(x, y) {
private #x, #y;
this.#x = x;
this.#y = y;
}
I keep seeing this basic constructor example. But isn't this the case that
Oliver raised of private being over generative? Those private names have
been generated and discarded, and those two fields can never be read again...
Oops, I left out the ellipses:
function Point(x, y) {
private #x, #y;
this.#x = x;
this.#y = y;
...
}
This is for instance-private instance variables.
If you want class-private instance variables, use
const Point = (function () {
private #x, #y;
return function Point(x, y) {
this.#x = #x;
this.#y = #y;
...
};
})();
(Allen mentioned function-own, aka static, as a way to avoid the module pattern
nesting and syn-tax, but that's a separate proposal.)
I'm still sympathetic to Oliver's objection that declaration-style private #x,
#y does not look generative enough. Agree that the sigil addresses Mark's
concern about confusing literal identifiers with lexically bound names, at a
Perlish price.
David F. mentioned script concatenation. It happens freely on the web, and it
is already biting us because of premature use strict usage where parts of the
concatenation violate strict mode and most browsers don't check yet
(https://bugzilla.mozilla.org/show_bug.cgi?id=579119).
To me this is the nail in the coffin for compilation unit private name scope.
I'm with dherman: lexical scope with a declaration for bindings, but it is not
clear how to make the declaration look more generative. It seems important for
similar things to look alike, and different-in-generativity/etc. things to look
different (somehow).
/be
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: New private names proposal
I think there are some interesting ideas to explore in both D. Flanagan's
proposal and D. Herman's variations upon it. However, they both seem to be
ignoring the second primary use case that I identified: conflict-free
extensions of build-in or third party objects. While naming conventions or a
sigil seems to be satisfactory to many as a way to implement weak
encapsulation. I don't think it works for the extension case.
On Dec 22, 2010, at 6:26 AM, David Herman wrote:
On Dec 22, 2010, at 2:00 AM, David Flanagan wrote:
On 12/22/2010 01:02 AM, David Herman wrote:
function Point(x, y) {
private #x, #y;
this.#x = x;
this.#y = y;
}
I keep seeing this basic constructor example. But isn't this the case that
Oliver raised of private being over generative? Those private names have
been generated and discarded, and those two fields can never be read again...
Oops, I left out the ellipses:
function Point(x, y) {
private #x, #y;
this.#x = x;
this.#y = y;
...
}
Of course, if you wanted to extend the scope further, you could lift it out
of the constructor.
As for the complaint of it being over-generative, that's mitigated in this
case by the sigil. For example, if you wrote:
function Point(x, y) {
private #x, #y;
this.#x = x;
this.#y = y;
}
Point.prototype = {
... #x ... #y ...
};
you'd get a compile-time error since #x and #y aren't in scope. Unless, of
course, they are already in scope as another private, although I'd expect
this kind of thing to be a bit rarer than variable scope errors since I would
guess private names wouldn't be nested and repurposed as often as variables
-- that's just a guess; it's hard to be sure.
Also, you can only take the but if you do it wrong, it doesn't work
arguments so far. After all, the generativity is by design. The question is
whether that design will be too surprising and confusing. We shouldn't make
JS too complicated or baroque, but we shouldn't nix an idea based on assuming
too little of programmers. IOW, I think the too complicated criticism
should be used with competent programmers in mind.
Anyway, I'm also just thinking out loud. :)
I like private as a keyword in object literals: it doesn't seem any more
confusing than get and set in literals. I don't like seeing it in functions
though: there it looks like a kind of var and const analog.
Isn't this less the case when what follows the keyword isn't an ordinary
identifier, i.e., has the sigil?
Is there any syntax from the old ES4 namespace stuff that could be applied
here?
An interesting thought, but I'm skeptical -- ES4 namespaces are pretty
dis-Harmonious, and for good reason: there be dragons. :)
Dave
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: New private names proposal
On Dec 22, 2010, at 9:47 AM, Brendan Eich wrote:
I'm still sympathetic to Oliver's objection that declaration-style private
#x, #y does not look generative enough. Agree that the sigil addresses
Mark's concern about confusing literal identifiers with lexically bound
names, at a Perlish price.
David F. mentioned script concatenation. It happens freely on the web, and it
is already biting us because of premature use strict usage where parts of
the concatenation violate strict mode and most browsers don't check yet
(https://bugzilla.mozilla.org/show_bug.cgi?id=579119).
To me this is the nail in the coffin for compilation unit private name
scope. I'm with dherman: lexical scope with a declaration for bindings, but
it is not clear how to make the declaration look more generative. It seems
important for similar things to look alike, and
different-in-generativity/etc. things to look different (somehow).
Consider
function f() {
var captured; //this generates a new long-lived data store
return {get value() {return captured}, set value(n) {captured=n}};
};
or
function g() {
function inner() {};
return inner;
}
I don't see why
private foo;
is any more or less generative than:
var captured;
or
function inner() {};
They are all are declarative forms and all implicitly generate new runtime
entities each time they are evaluated.
Allen___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: New private names proposal
On Dec 22, 2010, at 10:07 AM, Allen Wirfs-Brock wrote:
I don't see why
private foo;
is any more or less generative than:
var captured;
or
function inner() {};
They are all are declarative forms and all implicitly generate new runtime
entities each time they are evaluated.
The function case looks different enough, even if special in no common way with
object and array initialisers or regexps. All four of functionos, objectarray
initialisers, and regexp literals evaluated to fresh mutable objects, and
that's just something (or things) to know about the language.
For var captured; vs. private foo; there's a strange difference. These look
quite alike but the former allocates storage for one value and creates a
binding to that store. The latter does both of those things and generates a new
private name.
I agree that users could learn this and fold it into their knowledge of how the
language works. It would be another thing to know. It still seems slightly
off because var x; (no initializer) uses undefined. The private name generation
is novel, but not conveyed by the syntax.
/be
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: New private names proposal
On Dec 21, 2010, at 11:58 PM, Brendan Eich wrote: ... which is strictly weaker, more complex, and less explanatory. So is a transposed get from an inherited soft field. Soft fields change the way square brackets work in JS, for Pete's sake! They do not. Ok, then I'm arguing with someone else on that point. Many of us were wondering where my (shared) square brackets change for soft fields memory came from, and re-reading the numerous wiki pages. Finally we found what I had recollected in writing the above: http://wiki.ecmascript.org/doku.php?id=strawman:inherited_explicit_soft_fields#can_we_subsume_names There, after Mark's demurral (I (MarkM) do not like the sugar proposed for Names, ...), is this: If we wish to adopt the same sugar for soft fields instead, then private key; ... base[key] ... could expand to const key = SoftField(); ... key.get(base) If there are remaining benefits of Names not addressed above, here would be a good place to list them. If we can come to consensus that soft fields do subsume Names, then “Name” becomes a possible choice for the name of the “SoftField” constructor. - This is clearly pitting soft fields against names in full, including a change to JS's square bracket syntax as sugar. The hedging via If and the demurral do not remove this from the soft fields side of the death match I've been decrying, indeed they add to it. This is making a case for dropping names in full in favor of soft fields in (mostly -- no dot operator or object literal support) comparable fullness. For the record, and in case there's a next time: I don't think it's good form to chop up proposals made on the wiki (inherited soft fields, explicit soft fields, inherited explicit soft fields), put arguments about orthogonal syntax issues (the demurral even says orthogonal), and then use only some of the pieces to refute someone's argument based on the entirety of the wiki'ed work and the clear thrust of that work: to get rid of private names with something that is not a complete replacement. It doesn't really matter what one correspondent among many wants (IOW, it's not all out you [or me]). The argument is about a shared resource, the wiki at http://wiki.ecmascript.org/, and the strawman proposals on it that are advancing a particular idea (soft fields, with variations *and syntax*), and by doing so are trying to get rid of a different proposal (private names). In arguing about this, I have this bait-and-switch sense that I'm being told A+B, then when I argue in reply against B, I'm told no, no! only A!. (Cheat sheet: A is soft fields, B is transposed square bracket syntax for them.) Of course we should all separate syntax (we agree now; mea culpa for not doing my part earlier). But that didn't happen, even on the soft fields side. And the wiki'ed result, particularly the bit quoted above, is what everyone including me on the private names side (I want to have no side) who was reading the wiki indeed reacted to. I'm not saying this was any one person's malicious trick. But it's clear now what happened; the wiki and list record and diagram how it played out. It leaves a bad taste. /be ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: New private names proposal
On Dec 22, 2010, at 8:50 AM, Kevin Smith wrote:
From my perspective as a JS programmer, overloading the dot seems confusing.
The gains in elegance don't appear to me to be worth it. However,
overloading [] might be more acceptable:
[] gets no respect, I tell ya! ;-)
let x = new PrivateName();
// or perhaps:
private x;
function Point()
{
this[x] = 100;
}
function createPoint()
{
return {
[x]: 100,
};
This is an interesting idea, one I've heard about from Pythonistas who want
property names to be evaluated expressions, not implciitly quoted literals if
identifier-names, in object initialiser. It would save some amount of eval and
Function use.
It conflicts with the original MetaProperties syntax at
http://wiki.ecmascript.org/doku.php?id=strawman:object_initialiser_extensions
(grammar) and
http://wiki.ecmascript.org/doku.php?id=strawman:obj_initialiser_meta
(examples), which went like so:
var fancyObj = {
[proto: fancyProto, sealed]
prop1: value1,
. . .
};
but now uses instead of []. So no longer a strawman conflict, but I fear the
angle brackets are going to cause us some grammatical and nesting-in-HTML pain.
/be
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: New private names proposal
On 12/22/2010 09:57 AM, Allen Wirfs-Brock wrote:
I think there are some interesting ideas to explore in both D.
Flanagan's proposal and D. Herman's variations upon it. However, they
both seem to be ignoring the second primary use case that I identified:
conflict-free extensions of build-in or third party objects. While
naming conventions or a sigil seems to be satisfactory to many as a way
to implement weak encapsulation. I don't think it works for the
extension case.
Having to use # or [] to identify a private extension method would make
those extensions too ugly for common use, I suppose. I can't help
thinking that what you're trying to propose is a kind of poor-man's
private namespace. I don't know what the problems with ES4 namespaces
were nor how the current proposal avoids them.
In a subsequent message, Allen also wrote:
I don't see why
private foo;
is any more or less generative than:
var captured;
or
function inner() {};
They are all are declarative forms and all implicitly generate new runtime
entities each time they are evaluated.
I've now realized that I don't actually object so much to the generative
nature of private. What bugs me is that it essentially declares a
meta-identifier that is then used as if it were a regular identifier. It
is the meta-mismatch that I have a problem with.
If private foo declared a meta identifier foo, and I could then
write o.foo, that would make sense to me. But of course, that syntax
is more cumbersome than just using square brackets.
It feels to me as if the private declaration is behaving like a macro.
Are there precedents for this kind of meta-identifier in other languages?
David
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: New private names proposal
I think there are some interesting ideas to explore in both D. Flanagan's
proposal and D. Herman's variations upon it. However, they both seem to be
ignoring the second primary use case that I identified: conflict-free
extensions of build-in or third party objects. While naming conventions or a
sigil seems to be satisfactory to many as a way to implement weak
encapsulation. I don't think it works for the extension case.
I guess the intended spirit of my admittedly not-fully-specified idea last
night was that, other than the required '#' sigil, there's no major difference
from the private names strawman on the wiki. In particular, you could still
reify a private name in an expression context to get a value.
Let's just say, for the sake of concreteness, that the syntax would be:
PrimaryExpression ::= ... | '#' Identifier
So you could do, for example:
function gensym() {
private #x;
return #x;
}
The exact lexical syntax isn't so much the point as just trying to avoid the
ambiguity between public and private identifiers when used after dot or before
colon by using a distinct lexical syntax for private identifiers. This way you
don't have to know what's in scope to know *whether* an identifier is private.
Dave
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: New private names proposal
More musings: the current proposal allows this form where the generation
of the private name is explicit:
private x = new Name();
What if the silently generative form were not allowed? That would make
the mapping of identifiers more explicit.
And if so, could we replace = with a token that indicates mapping?
private x = new Name();
What about mapping public identifiers to other public identifiers?
private cos = cosine // Now I can write Math.cosine()
If that is allowed then the private keyword no longer makes sense.
How about something like the let statement:
var privateX = new Name(), privateY = new Name()
for (x,y) use (privateX, privateY) {
// Identifier mapping scoped to this block
}
Or flip the for and use clauses around if that looks too much like a loop:
use(new Name(), new Name()) for (x, y) {}
David
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: New private names proposal
On Tue, Dec 21, 2010 at 2:44 PM, Allen Wirfs-Brock al...@wirfs-brock.com
wrote:
Please don't totally disengage from the syntax discussion. Most
programmers understanding of the language starts with the concrete (syntax)
and then proceeds to the abstract (semantics). Syntax design can have a big
impact on the usability of the underlying semantics
Ok, I am not sure what I think of the following idea, but it's a bit
different in flavor and so may stimulate other thoughts. I will express the
expansion in terms of the natural expansion for a soft fields underpinning.
One could do an equally natural expansion for private names. == means
expands to. Actual expansions would be a bit more complex to preserve the
left-to-right order of evaluation of the original.
The basic idea is, since we're considering a sigil anyway, and since .# and
[# would both treat the thing to their right as something to be evaluated,
why not turn the sigil into an infix operator instead? Then it can be used
as .-like []-like without extra notation or being too closely confused
with . or [] themselves. Finally, given the meaning of the sigil-turned
operator, @ seemed to read better to me than #. YMMV.
expr1 @ expr2
==
expr2.get(expr1)
expr1 @ expr2 = expr3;
==
expr2.set(expr1, expr3);
const obj = {...@expr1: expr2, ...};
==
const obj = {...}; expr1.set(obj, expr2);
Perhaps the expression on the right need not be a Name/SoftField. It could
be anything that responds to get and set.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: New private names proposal
Hi David, First of all, I think you may not be reading the current private names proposal. Allen wanted to change the name so he created a new page: http://wiki.ecmascript.org/doku.php?id=strawman:private_names Part of what you're reacting against is in fact what he changed (more below). But let me answer your question to provide some background. It feels to me as if the private declaration is behaving like a macro. Are there precedents for this kind of meta-identifier in other languages? It might be illuminating to know that this whole line of exploration started when I was reading the documentation for PLT Scheme (now called Racket), which has a library for creating generative, lexically scoped names for use with their object system. You can write: (define-local-member-name foo) and then use `foo' as a property in a class, and only the code in the scope of the `define-local-member-name' can access that property name. In other words, that's where I got the idea for the original private names proposal. And yes, internally, the implementation defines `foo' as a macro that expands into the gensym'ed name. What also might be illuminating is the fact that this is part of the Scheme way of doing things, which is never to have more than one lexical environment. So absolutely everything in Scheme shares a single namespace -- `define-local-member-name' and macros and keywords and variables and anything fancy new binding forms you can invent (via macros, of course!). I probably followed this approach without even thinking explicitly about it, because I'm so used to the Scheme Way. :) So my original proposal worked very much the same as `define-local-member-name'. But Allen convinced me that there are drawbacks to having the single namespace, especially since '.' and ':' are a separate syntactic space from variable references. He reworked the proposal so that `private' binds in a *separate* namespace from variables, so there's no conflict between the two. Take a look at his proposal and see what you think. Dave ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: New private names proposal
On Dec 22, 2010, at 7:10 AM, Peter van der Zee wrote:
What about adding an attribute to properties that somehow identify which
classes (in the prototype chain for protected) have access to the object?
I'll leave the somehow up in the air, but you could introduce a [[Private]]
attribute which, if not undefined, says which context must be set (and for
protected, either directly or through the prototypal chain of the current
context) to gain access to this property. And if that context is not found,
some error is thrown. Maybe it would be [[EncapsulationType]] :: {private,
protected, public} and [[EncapsulationContext]] :: ?. You could also add a
simple api to check for these (isPrivate, isProtected, isPublic,
hasEncapsulatedProperty, etc) depending on how it would affect in and
enumeration.
IMO, this is too class-oriented for JS. We should allow the creation of private
members of arbitrary objects, not just those that inherit from new
constructors. I think it also doesn't address the use case of adding new
operations to existing classes like Object or Array without danger of name
conflicts.
Pro's:
- meaning of private will be more to what people expect
I find this a little hard to believe. It's tricky to make claims about what
people will expect. It's true this feels somewhat analogous to Java, but
there's a wide diversity of JS programmers. And a lot of them don't want us to
just make it like Java and do their best to remind us of this fairly
regularly. ;)
- minimal magic going on, trying to access a private property out of scope
should result in a proper error
- possibly less impact on the spec (although I'm not sure there...)
- no need to introduce a new type/class to denote private properties
This last point confuses me -- it sounds like you *have* to introduce a class
to denote private properties, because they're associated with a class. Or are
you referring to the SoftField type?
Dave
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: New private names proposal
On Wed, Dec 22, 2010 at 11:56 AM, Mark S. Miller erig...@google.com wrote:
On Tue, Dec 21, 2010 at 2:44 PM, Allen Wirfs-Brock al...@wirfs-brock.com
wrote:
Please don't totally disengage from the syntax discussion. Most
programmers understanding of the language starts with the concrete (syntax)
and then proceeds to the abstract (semantics). Syntax design can have a big
impact on the usability of the underlying semantics
Ok, I am not sure what I think of the following idea, but it's a bit
different in flavor and so may stimulate other thoughts. I will express the
expansion in terms of the natural expansion for a soft fields underpinning.
One could do an equally natural expansion for private names. == means
expands to. Actual expansions would be a bit more complex to preserve the
left-to-right order of evaluation of the original.
The basic idea is, since we're considering a sigil anyway, and since .# and
[# would both treat the thing to their right as something to be evaluated,
why not turn the sigil into an infix operator instead? Then it can be used
as .-like []-like without extra notation or being too closely confused
with . or [] themselves. Finally, given the meaning of the sigil-turned
operator, @ seemed to read better to me than #. YMMV.
expr1 @ expr2
==
expr2.get(expr1)
expr1 @ expr2 = expr3;
==
expr2.set(expr1, expr3);
const obj = {...@expr1: expr2, ...};
==
const obj = {...}; expr1.set(obj, expr2);
Perhaps the expression on the right need not be a Name/SoftField. It could
be anything that responds to get and set.
Redoing the class private example at the end of
http://wiki.ecmascript.org/doku.php?id=strawman:private_names#using_private_identifiers
http://wiki.ecmascript.org/doku.php?id=strawman:names_vs_soft_fields#using_private_identifiers
const key = SoftField(); // or, obviously, Name(),
depending...function Thing() {
this @ key = class private value;
this.hasKey = function(x) {
return x @ key === this @ key;
};
this.getThingKey = function(x) {
return x @ key;
};}
var thing1 = new Thing;var thing2 = new Thing;
print(key in thing1); // falseprint(thing1.hasKey(thing1));
// trueprint(thing1.hasKey(thing2)); // true
--
Cheers,
--MarkM
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: New private names proposal
On Dec 22, 2010, at 7:10 AM, Peter van der Zee wrote:
What about adding an attribute to properties that somehow
identify which classes (in the prototype chain for protected)
have access to the object? I'll leave the somehow up in the
air, but you could introduce a [[Private]] attribute which, if
not undefined, says which context must be set (and for protected,
either directly or through the prototypal chain of the current
context) to gain access to this property. And if that context is
not found, some error is thrown. Maybe it would be
[[EncapsulationType]] :: {private, protected, public} and
[[EncapsulationContext]] :: ?. You could also add a simple api
to check for these (isPrivate, isProtected, isPublic,
hasEncapsulatedProperty, etc) depending on how it would affect
in and enumeration.
IMO, this is too class-oriented for JS. We should allow the
creation of private members of arbitrary objects, not just those
that inherit from new constructors. I think it also doesn't address
the use case of adding new operations to existing classes like
Object or Array without danger of name conflicts.
Ok. Indeed it doesn't address adding private properties to any object nor
extending existing classes, although I think that might be fixable. And you're
right, it doesn't address conflicts.
Pro's:
- meaning of private will be more to what people expect
I find this a little hard to believe. It's tricky to make claims
about what people will expect. It's true this feels somewhat
analogous to Java, but there's a wide diversity of JS programmers.
And a lot of them don't want us to just make it like Java and do
their best to remind us of this fairly regularly. ;)
Ok, fair enough.
there...) - no need to introduce a new type/class to denote
private properties
This last point confuses me -- it sounds like you *have* to
introduce a class to denote private properties, because they're
associated with a class. Or are you referring to the SoftField type?
The proposal at http://wiki.ecmascript.org/doku.php?id=strawman:private_names
lists three changes right at the top. 1 is a new type. To me, this seems like a
rather big impact on the language for introducing something that's already
possible through closures.
- peter
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: New private names proposal
On Dec 22, 2010, at 11:12 AM, David Flanagan wrote:
've now realized that I don't actually object so much to the generative
nature of private. What bugs me is that it essentially declares a
meta-identifier that is then used as if it were a regular identifier. It is
the meta-mismatch that I have a problem with.
JavaScript already has such meta identifiers. But they can't be used as
regular identifiers (which I'll interpret as meaning expression contexts),
instead they only occur after a dot or on the left hand side of a colon in an
object literal. the private names proposals creates the exact same kind of
meta identifier for use in the exact same contexts (and adds a new #.
context). It simply extends the scoping and binding of such meta identifiers.
More explicitly in JavaScript:
var x= new Object;
var obj={x:x}; //same identifier, two different meanings
obj.obj=obj;
If private foo declared a meta identifier foo, and I could then write
o.foo, that would make sense to me. But of course, that syntax is more
cumbersome than just using square brackets.
It feels to me as if the private declaration is behaving like a macro.
Are there precedents for this kind of meta-identifier in other languages?
For example, member names in C structs scope to the type that defines them
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: New private names proposal
On Dec 22, 2010, at 12:45 PM, Peter van der Zee wrote: IMO, this is too class-oriented for JS. We should allow the creation of private members of arbitrary objects, not just those that inherit from new constructors. I think it also doesn't address the use case of adding new operations to existing classes like Object or Array without danger of name conflicts. Ok. Indeed it doesn't address adding private properties to any object nor extending existing classes, although I think that might be fixable. And you're right, it doesn't address conflicts. Hold this thought ;-). there...) - no need to introduce a new type/class to denote private properties This last point confuses me -- it sounds like you *have* to introduce a class to denote private properties, because they're associated with a class. Or are you referring to the SoftField type? The proposal at http://wiki.ecmascript.org/doku.php?id=strawman:private_names lists three changes right at the top. 1 is a new type. To me, this seems like a rather big impact on the language for introducing something that's already possible through closures. Wait, closures can't be used to avoid name collisions when extending existing objects (that held thought). The new type would be an internal, spec-only thing, were it not for #.id -- that requires typeof #.id == private name or some such. It all follows, but it's a hornet's nest in my view. An object subtype (internal [[Class]] property with new value PrivateName, e.g.) would be less bitey. Allen's strawman raises this possibility, so it's not really the hill to die on -- it's not a big deal over which to shoot down the whole proposal. But it does draw fire that we might prefer held for bigger targets, I agree. /be ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: New private names proposal
On 2010-12-22 07:57, Brendan Eich wrote: On Dec 21, 2010, at 10:22 PM, David-Sarah Hopwood wrote: On 2010-12-21 22:12, Brendan Eich wrote: It's tiresome to argue by special pleading that one extension or transformation (including generated symbols) is more complex, and less explanatory, while another is less so, when the judgment is completely subjective. And the absolutism about how it's *always* better in every instance to use strong encapsulation is, well, absolutist (i.e., wrong). I gave clear technical arguments in that post. If you want to disagree with them, disagree with specific arguments, rather than painting me as an absolutist. (I'm not.) Here's a quote: As you can probably tell, I'm not much impressed by this counterargument. It's a viewpoint that favours short-termism and code that works by accident, rather than code that reliably works by design. How do you expect anyone to respond? By endorsing bugs or programming based on partial knowledge and incomplete understanding? Yet the real world doesn't leave us the option to be perfect very often. This is what I mean by absolutism. That isn't what absolutism generally means, so you could have been clearer. What I said, paraphrasing, is that weak encapsulation favours code that doesn't work reliably in cases where the encapsulation is bypassed. Also, that if the encapsulation is never bypassed then it didn't need to be weak. What's wrong with this argument? Calling it absolutist is just throwing around insults, as far as I'm concerned. When prototyping, weak or even no encapsulation is often the right thing, but you have to be careful with prototypes that get pressed into products too quickly (I should know). JS is used to prototype all the time. OK, let's consider prototyping. In the soft fields proposal, a programmer could temporarily set a variable that would otherwise have held a soft field to a string. All accesses via that variable will work, but so will encapsulation-breaking accesses via the string name. Then before we release the code, we can put back the soft field (requiring only minimal code changes) and remove any remaining encapsulation-breaking accesses. Does this address the issue? So rather than argue for strong encapsulation by setting up a straw man counterargument you then are not much impressed by, decrying short-termism, etc., I think it would be much more productive to try on others' hats and model their concerns, including for usable syntax. Weak vs strong encapsulation is mostly independent of syntax. At least, all of the syntaxes that have been proposed so far can provide either strong or weak encapsulation, depending on the semantics. There is a separate discussion to be had about whether the form of executable specification MarkM has used (not to be confused with the semantics) is the best form to use for any final spec. Personally, I like this form of specification: I think it is clear, concise (which aids holding the full specification of a feature in short-term memory), easy to reason about relative to other approaches, useful for prototyping, and useful for testing. I don't mind at all that the correspondance with the implementation is less direct than it would be in a more operational style; implementors often need to handle less direct mappings than this, and I don't expect a language specification to be a literal description of how a language is implemented in general (excluding naive reference implementations). Once again, you've argued about what you like, with subjective statements such as I don't mind. Yes, I try very hard not to misrepresent opinions as facts. With inherited soft fields, the ability to extend frozen objects with private fields is an abstraction leak (and a feature, I agree). How is it an abstraction leak? The abstraction is designed to allow this; it's not an accident (I'm fairly sure, without mind-reading MarkM). If I give you an object but I don't want you adding fields to it, what do I do? Freezing works with private names, but it does not with soft fields. What's your intended goal in preventing adding fields to the object? If the goal is security or encapsulation, then freezing the object is sufficient. If I add the field in a side table, that does not affect your use of the object. I could do the same thing with aWeakMap.set(obj, value). If the goal is concurrency-safety, then we probably need to have a concurrency model in mind before discussing this in detail. However, adding fields in a side table does not affect the concurrency-safety of your code that does not have access to the table or those fields. It might affect the concurrency-safety of my code that does have that access; so I shouldn't add new fields and rely on my view of the object to be concurrency-safe just because the object is frozen. This doesn't seem like an onerous or impractical restriction. With private names, the inability to
Re: New private names proposal
On 2010-12-22 18:59, Brendan Eich wrote: On Dec 21, 2010, at 11:58 PM, Brendan Eich wrote: ... which is strictly weaker, more complex, and less explanatory. So is a transposed get from an inherited soft field. Soft fields change the way square brackets work in JS, for Pete's sake! They do not. Ok, then I'm arguing with someone else on that point. Many of us were wondering where my (shared) square brackets change for soft fields memory came from, and re-reading the numerous wiki pages. Finally we found what I had recollected in writing the above: http://wiki.ecmascript.org/doku.php?id=strawman:inherited_explicit_soft_fields#can_we_subsume_names There, after Mark's demurral (I (MarkM) do not like the sugar proposed for Names, ...), is this: If we wish to adopt the same sugar for soft fields instead, then private key; ... base[key] ... could expand to const key = SoftField(); ... key.get(base) If there are remaining benefits of Names not addressed above, here would be a good place to list them. If we can come to consensus that soft fields do subsume Names, then “Name” becomes a possible choice for the name of the “SoftField” constructor. - This is clearly pitting soft fields against names in full, including a change to JS's square bracket syntax as sugar. The hedging via If and the demurral do not remove this from the soft fields side of the death match I've been decrying, indeed they add to it. This is making a case for dropping names in full in favor of soft fields in (mostly -- no dot operator or object literal support) comparable fullness. For the record, and in case there's a next time: I don't think it's good form to chop up proposals made on the wiki (inherited soft fields, explicit soft fields, inherited explicit soft fields), put arguments about orthogonal syntax issues (the demurral even says orthogonal), and then use only some of the pieces to refute someone's argument based on the entirety of the wiki'ed work and the clear thrust of that work: to get rid of private names with something that is not a complete replacement. It doesn't really matter what one correspondent among many wants (IOW, it's not all out you [or me]). The argument is about a shared resource, the wiki at http://wiki.ecmascript.org/, and the strawman proposals on it that are advancing a particular idea (soft fields, with variations *and syntax*), and by doing so are trying to get rid of a different proposal (private names). In arguing about this, I have this bait-and-switch sense that I'm being told A+B, then when I argue in reply against B, I'm told no, no! only A!. (Cheat sheet: A is soft fields, B is transposed square bracket syntax for them.) This criticism is baseless and without merit. In order to compare the two semantic proposals, http://wiki.ecmascript.org/doku.php?id=strawman:inherited_explicit_soft_fields#can_we_subsume_names considers what they would look like with the same syntax. In that case, soft fields are semantically simpler. This should not in any way preclude also criticising the syntax. If your criticisms of soft fields plus the change to [] depended on the fact that the syntax change was layered on soft fields, then you might have a point. But in fact those criticisms apply to the syntax change regardless of which proposal it is layered on. There was and is no bait and switch. I'm not saying this was any one person's malicious trick. But it's clear now what happened; the wiki and list record and diagram how it played out. It leaves a bad taste. You have willfully assumed bad faith, despite clear explanations. That certainly does leave a bad taste. -- David-Sarah Hopwood ⚥ http://davidsarah.livejournal.com signature.asc Description: OpenPGP digital signature ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: New private names proposal
On Dec 22, 2010, at 2:56 PM, David-Sarah Hopwood wrote:
What I said, paraphrasing, is that weak encapsulation favours code that
doesn't work reliably in cases where the encapsulation is bypassed. Also,
that if the encapsulation is never bypassed then it didn't need to be weak.
What's wrong with this argument?
The reliability point is fine but not absolute. Sometimes reliability is not
primary.
You may disagree, but every developer knows this who has had to meet a
deadline, where missing the deadline meant nothing further would be developed
at all, while hitting the deadline in a hurry, say without strong
encapsulation, meant there was time to work on stronger encapsulation and other
means to achieve the end of greater reliability -- but *later*, after the
deadline. At the deadline, the demo went off even though reliability bugs were
lurking. They did not bite.
This is a common story from successful startups that I've been part of or
advised.
The second part, asserting that if the encapsulation was never bypassed then it
didn't need to be weak, as if that implies it might as well have been strong,
assumes that strong is worth its costs vs. the (not needed, by the hypothesis)
benefits.
But that's not obviously true, because strong encapsulation does have costs as
well as benefits. It's often worth it, but not always. It may cost more than
weak in the short run, but not the long run. It may cost more than it benefits
in any time frame.
Yet your argument tries to say strong encapsulation is absolutely always worth
it, since either it was needed for reliability, or else it wouldn't have hurt.
This completely avoids the economic trade-offs -- the costs over time. Strong
can hurt if it is unnecessary.
To be utterly concrete in the current debate: I'm prototyping something in a
browser-based same-origin system that already uses plain old JS objects with
properties. The system also has an inspector written in JS. Oh, and the system
uses a framework where objects can be cloned using ES5's new meta-object APIs
called by a clone method.
Now I want to make a private member of my objects, not for security but just to
save my code from myself, who tends to use .x as a property name too much, and
my colleague MonkeyBob, who likes to monkey-patch.
With private names, I just need to add the *** line to my constructor:
function MyConstructor(x, ...) {
private x; // ***
this.x = x;
... // closures defined that use x
}
and I'm better off. Even if ES5's Object.getOwnPropertyNames is used by the
inspector run by my other colleague ReliableFred, who needs to see x even
though it is private. Fred won't do anything wrong with the value of x, but if
he can't see it, he can't debug his code, which uses my code (the bug could be
anywhere, or multi-factorial).
With soft fields, one has to write strictly more code:
function MyConstructor(x, ...) {
const mySoftField = SoftField();
mySoftField.set(this, x);
... // closures defined that use mySoftField
}
And what's worse, I've broken ReliableFred's benign inspector use-case. And
I've also broken clone. My boss finds out and fires me, we miss the demo
deadline and fail to get funding, the company fails. Even the strong
encapsulation angels cry tears of blood.
[big snip]
I've also stated clearly *why* I want strong encapsulation, for both
security and software engineering reasons. To be honest, I do not know
why people want weak encapsulation. They have not told us.
Yes, they have. In the context of this thread, Allen took the trouble to write
this section:
http://wiki.ecmascript.org/doku.php?id=strawman:private_names#private_name_properties_support_only_weak_encapsulation
Quoting: Private names are instead intended as a simple extensions of the
classic JavaScript object model that enables straight-forward encapsulation in
non-hostile environments. The design preserves the ability to manipulate all
properties of an objects at a meta level using reflection and the ability to
perform “monkey patching” when it is necessary.
/be
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: New private names proposal
On Dec 22, 2010, at 3:49 PM, David-Sarah Hopwood wrote: In arguing about this, I have this bait-and-switch sense that I'm being told A+B, then when I argue in reply against B, I'm told no, no! only A!. (Cheat sheet: A is soft fields, B is transposed square bracket syntax for them.) This criticism is baseless and without merit. In order to compare the two semantic proposals, http://wiki.ecmascript.org/doku.php?id=strawman:inherited_explicit_soft_fields#can_we_subsume_names considers what they would look like with the same syntax. Wrong. That section has private key; ... base[key] ... and thus assumes private key creates a private-name value bound to key that can be used in brackets. That is *not* how private names as proposed by Allen works, nor how the earlier names proposal worked. Private names, and names before it, proposes lexical bindings for private names which can be used only after dot in a member expression and before colon in an object initialiser's property initialiser. A private-declared name cannot be used in brackets to get at the property -- not without #. to reflect it into runtime. Clearly, the http://wiki.ecmascript.org/doku.php?id=strawman:inherited_explicit_soft_fields#can_we_subsume_names gets this wrong. Either the names proposal was misunderstood, or the square-bracket-only syntax was a compromise. It simply is not and never was the same syntax. In that case, soft fields are semantically simpler. I reject all your premises, so it is pointless to argue about conclusions that depend on them. First, the simpler semantics for a different, inferior syntax does not win over more complex semantics for a simpler and more usable syntax. Users of the language are the audience in most need of simplicity, not implementors or spec writers. The spec is not the ultimate good to optimize in this way. Second, the soft fields semantic model is not simpler when you count everything it depends on, and where it shifts complexity (implementors and users). Finally, I disagree that an executable spec, aka self-hosted library code as spec, wins. But see below -- at this point, it's clear we should not be arguing about soft fields vs. private names as if they are alternatives or in any way substitutable. I'm not saying this was any one person's malicious trick. But it's clear now what happened; the wiki and list record and diagram how it played out. It leaves a bad taste. You have willfully assumed bad faith, despite clear explanations. That certainly does leave a bad taste. No, I explicitly disclaimed bad faith in the cited first line above (I'm not saying this was any one person's malicious 'trick'.). Putting up a bunch of wiki pages with the intent of knocking down a different proposal *is* aggressive. I don't think that's bad faith and I never said so. Crock cheered it on. In accusing me of assuming bad faith, you are just missing the target completely. But any such (premature or just wrong) contest between proposals has to compare apples to apples. We can't even agree on the syntax apples, never mind how to compare the semantic model apples. Even with the best faith (which I presume MarkM has, and he knows this), trying to compare different semantic models, tracking multiple wiki pages, while setting up an elimination-contest context, is tricky, as in, a lot can go wrong. And (see above, where you repeat the falsehood that Mark's section can_we_subsume_names uses the same syntax as private names or names) things did go wrong. I now think it is a mistake to try to build consensus by separating syntax from semantics, mapping one chopped-down, feature-stripped syntax to both private names and soft fields, and essentially joining in the campaign to make there be only one (among two proposals). Here's why: Private names have nothing to do with soft fields. They are an independent proposal. Soft fields do not need more than weak maps, which are already harmonious. If you don't like private names, fine. Maybe they won't make it. Or with feedback from this list and the community, they might evolve to something that gets into a future edition, but soft fields don't bear on the odds at all. Trying to replace private names with (inevitably different) syntax mapped to soft fields is not going to please fans of either proposal. /be ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: New private names proposal
On 2010-12-23 00:40, Brendan Eich wrote: On Dec 22, 2010, at 2:56 PM, David-Sarah Hopwood wrote: What I said, paraphrasing, is that weak encapsulation favours code that doesn't work reliably in cases where the encapsulation is bypassed. Also, that if the encapsulation is never bypassed then it didn't need to be weak. What's wrong with this argument? The reliability point is fine but not absolute. Sometimes reliability is not primary. You may disagree, but every developer knows this who has had to meet a deadline, where missing the deadline meant nothing further would be developed at all, while hitting the deadline in a hurry, say without strong encapsulation, meant there was time to work on stronger encapsulation and other means to achieve the end of greater reliability -- but *later*, after the deadline. At the deadline, the demo went off even though reliability bugs were lurking. They did not bite. How precisely would weak encapsulation (specifically, a mechanism that is weak because of the reflection and proxy trapping loopholes) help them to meet their deadline? (I don't find your inspector example compelling, for reasons given below.) The second part, asserting that if the encapsulation was never bypassed then it didn't need to be weak, as if that implies it might as well have been strong, assumes that strong is worth its costs vs. the (not needed, by the hypothesis) benefits. But that's not obviously true, because strong encapsulation does have costs as well as benefits. What costs are you talking about? - Not specification complexity, because the proposal that has the simplest spec complexity so far (soft fields, either with or without syntax changes) provides strong encapsulation. - Not runtime performance, because the strength of encapsulation makes no difference to that. - Not syntactic convenience, because there exist both strong-encapsulation and weak-encapsulation proposals with the same syntax. - Not implementation complexity, because that's roughly similar. So, what costs? It is not an axiom that proposals with any given desirable property have greater cost (in any dimension) than proposals without that property. Yet your argument tries to say strong encapsulation is absolutely always worth it, since either it was needed for reliability, or else it wouldn't have hurt. This completely avoids the economic trade-offs -- the costs over time. Strong can hurt if it is unnecessary. How precisely can it hurt, relative to using the same mechanism with loopholes? To be utterly concrete in the current debate: I'm prototyping something in a browser-based same-origin system that already uses plain old JS objects with properties. The system also has an inspector written in JS. [snip example in which the only problem is that the inspector doesn't show private fields because it is using getOwnPropertyNames] Inspectors can bypass encapsulation regardless of the language spec. Specifically, an inspector that supports Harmony can see that there is a declaration of a private variable x, and show that field on any objects that are being inspected. It can also display the side table showing the value of x for all objects that have that field. Disadvantages: slightly greater implementation complexity in the inspector, and lack of compatibility with existing inspectors that don't explicitly support Harmony. Note that inspectors for JS existed prior to the addition of getOwnPropertyNames, so that is merely a convenience and a way to avoid implementation dependencies in the inspector. With soft fields, one has to write strictly more code: Nope, see above. I've also stated clearly *why* I want strong encapsulation, for both security and software engineering reasons. To be honest, I do not know why people want weak encapsulation. They have not told us. Yes, they have. In the context of this thread, Allen took the trouble to write this section: http://wiki.ecmascript.org/doku.php?id=strawman:private_names#private_name_properties_support_only_weak_encapsulation Quoting: Private names are instead intended as a simple extensions of the classic JavaScript object model that enables straight-forward encapsulation in non-hostile environments. The design preserves the ability to manipulate all properties of an objects at a meta level using reflection and the ability to perform “monkey patching” when it is necessary. Strong encapsulation does not interfere with the ability to add new monkey-patched properties (actually fields). What it does prevent, by definition, is the ability to modify or read existing private fields to which the accessor does not have the relevant field object. What I was looking for was not mere assertion that this is sometimes necessary to be able to do that, but an explanation of why. As for the ability to manipulate all properties of objects at a meta level using reflection, strictly speaking that is still
Re: New private names proposal
On Dec 22, 2010, at 6:39 PM, David-Sarah Hopwood wrote:
Inspectors can bypass encapsulation regardless of the language spec.
The Inspector is written in ES5. How does it bypass soft field strong
encapsulation?
As for the ability to manipulate all properties of objects at a meta
level using reflection, strictly speaking that is still possible in the
soft fields proposal because soft fields are not properties. This is not
mere semantics; these fields are associated with the object, but it is
quite intentional that the object model views them as being stored on a
side table.
The side table is in a closure environment only, not available to the
inspector, which uses getOwnPropertyNames:
function MyConstructor(x, ...) {
const mySoftField = SoftField();
mySoftField.set(this, x);
... // closures defined that use mySoftField
}
Note that other methods of associating private state with an
object, such as closing over variables, do not allow that state to be
accessed by reflection on the object either.
That's right, and that is exactly Allen's point in writing the rationale for
weak encapsulation that he wrote, and my point in using the example
ReliableFred relies upon: an inspector hosted in the browser written in ES5.
You wrote too long a reply again, with lots of extra words claiming to rebut
me, but you got this fundamental part of the example completely wrong, and
inverted the rationale for weak encapsulation.
We do not want to require a deoptimizing native code hosted debugger or
inspector to peek in closures. Even if you have one, finding the soft field
requires the user to know where to look. With private names, there's no
mystery: you look on the object itself, using getOwnPropertyNames.
Please reply in 500 words.
/be___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: New private names proposal
On 2010-12-23 01:11, Brendan Eich wrote: On Dec 22, 2010, at 3:49 PM, David-Sarah Hopwood wrote: In arguing about this, I have this bait-and-switch sense that I'm being told A+B, then when I argue in reply against B, I'm told no, no! only A!. (Cheat sheet: A is soft fields, B is transposed square bracket syntax for them.) This criticism is baseless and without merit. In order to compare the two semantic proposals, http://wiki.ecmascript.org/doku.php?id=strawman:inherited_explicit_soft_fields#can_we_subsume_names considers what they would look like with the same syntax. Wrong. That section has private key; ... base[key] ... and thus assumes private key creates a private-name value bound to key that can be used in brackets. That is *not* how private names as proposed by Allen works, nor how the earlier names proposal worked. That section is clear that it is talking about the syntax proposed in http://wiki.ecmascript.org/doku.php?id=strawman:names. (Adapting it to the private_names syntax is trivial, though.) The Name objects as property names section of that page gives an example in which 'var name = new Name' creates an object that can be used via 'obj[name]'. The Binding private names section says that in the scope of a 'private x' declaration, x is also bound as a plain variable to the Name value. Therefore, 'private key;' binds the plain variable 'key' to a Name value which can be used as 'base[key]'. Your interpretation of the names proposal is wrong and Mark's was correct. As far as I can see, MarkM has not (at least, not on the wiki) proposed any new syntax in this discussion that had not already been proposed in one of Allen's proposals. Private names, and names before it, proposes lexical bindings for private names which can be used only after dot in a member expression and before colon in an object initialiser's property initialiser. A private-declared name cannot be used in brackets to get at the property -- not without #. to reflect it into runtime. Clearly, the http://wiki.ecmascript.org/doku.php?id=strawman:inherited_explicit_soft_fields#can_we_subsume_names gets this wrong. You apparently missed the statement x is also bound as a plain variable to the Name value. in the names proposal, which would explain your confusion on this point. Either the names proposal was misunderstood, or the square-bracket-only syntax was a compromise. It simply is not and never was the same syntax. In that case, soft fields are semantically simpler. I reject all your premises, so it is pointless to argue about conclusions that depend on them. Do you still reject them after being shown that the syntax in MarkM's proposal is in fact the same syntax? First, the simpler semantics for a different, inferior syntax does not win over more complex semantics for a simpler and more usable syntax. Users of the language are the audience in most need of simplicity, not implementors or spec writers. The spec is not the ultimate good to optimize in this way. This argument clearly fails, because the syntax that you're criticising as inferior is actually the syntax defined in the names proposal. There is no obstacle whatsoever to the soft fields semantics being used with any of the syntaxes that have been proposed so far. Second, the soft fields semantic model is not simpler when you count everything it depends on, and where it shifts complexity (implementors and users). OK, there's an interesting point here, which is the extent to which reliance on existing language constructs (existing in the sense of not added as part of the feature under consideration), should be counted toward a new feature's complexity, relative to reliance on new constructs added together with the feature. I think that use of new constructs ought to be charged more in complexity cost than use of existing constructs, all else being equal. This is an opinion, but I would have thought it's a rather uncontroversial one. In any case, I don't find WeakMap (or other constructs used by the SoftField executable specification) particularly complex. YMMV. The soft fields model does not shift complexity onto users because their perception of complexity depends mainly on the syntax, which is the same. The differences in semantics are unlikely to be noticed in most situations. The actual implementation complexity is no greater for soft fields. The soft fields specification has a less direct correspondance to the implementation, and we disagree on the significance of that. Finally, I disagree that an executable spec, aka self-hosted library code as spec, wins. But see below -- at this point, it's clear we should not be arguing about soft fields vs. private names as if they are alternatives or in any way substitutable. We're not going to be able to agree on adding both, so they are alternatives. I'm not saying this was any one person's malicious trick. But it's clear now what happened; the
Re: New private names proposal
On 2010-12-23 02:48, Brendan Eich wrote:
On Dec 22, 2010, at 6:39 PM, David-Sarah Hopwood wrote:
Inspectors can bypass encapsulation regardless of the language spec.
The Inspector is written in ES5. How does it bypass soft field strong
encapsulation?
I meant, obviously, that inspectors in general can bypass encapsulation.
It is not clear to me that a usable inspector can be written purely in
ES5 using the reflection API. Doesn't an inspector have to be able to read
variables in any scope? Or maybe you mean by inspector something less
ambitious than I'm thinking of (but then it's not clear that it needs to
be able to read private fields, since it also can't read closed-over
variables).
As for the ability to manipulate all properties of objects at a meta
level using reflection, strictly speaking that is still possible in the
soft fields proposal because soft fields are not properties. This is not
mere semantics; these fields are associated with the object, but it is
quite intentional that the object model views them as being stored on a
side table.
The side table is in a closure environment only, not available to the
inspector, which uses getOwnPropertyNames:
function MyConstructor(x, ...) {
const mySoftField = SoftField();
mySoftField.set(this, x);
... // closures defined that use mySoftField
}
OK, you're assuming that the inspector can't read state from closures.
So why does it matter that it can't read private fields, given that the
programmer would probably have used closures if they were not using
private fields?
Note that other methods of associating private state with an
object, such as closing over variables, do not allow that state to be
accessed by reflection on the object either.
That's right, and that is exactly Allen's point in writing the rationale
for weak encapsulation that he wrote, and my point in using the example
ReliableFred relies upon: an inspector hosted in the browser written in ES5.
The constraint that the inspector be written in ES5 seems to be a purely
artificial one. All of the commonly used browsers have debugger extensions.
Please reply in 500 words.
No, I'm not going to play your word-counting game.
--
David-Sarah Hopwood ⚥ http://davidsarah.livejournal.com
signature.asc
Description: OpenPGP digital signature
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: New private names proposal
On Dec 22, 2010, at 7:34 PM, David-Sarah Hopwood wrote: As far as I can see, MarkM has not (at least, not on the wiki) proposed any new syntax in this discussion that had not already been proposed in one of Allen's proposals. Wrong again. Allen did not write the original strawman:names proposal.-- from the top of private_names: Original proposal by Dave Herman and Sam Tobin-Hochstadt is here. Follow that link and read http://wiki.ecmascript.org/doku.php?id=strawman:names#binding_private_names to see only examples using x.key, etc. -- no square brackets. Mark's example predates private_names and so may have worked in the old names proposal, but only via square brackets. Not via dot -- so again *not* the same syntax as what even strawman:names proposed. Never mind the private names proposal that supersedes names -- not faulting Mark for lacking clairvoyance here -- I'm faulting you for twisting the same syntax from its obvious meaning of all the same syntax to the subset that uses square brackets. You seem to have problem owning up to mistakes. I've counted four so far and each time I point them out you either deny with lots of words, or ignore. This makes it hard to justify continuing our little exchange. /be ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: New private names proposal
On Dec 22, 2010, at 7:49 PM, David-Sarah Hopwood wrote: On 2010-12-23 02:48, Brendan Eich wrote: On Dec 22, 2010, at 6:39 PM, David-Sarah Hopwood wrote: Inspectors can bypass encapsulation regardless of the language spec. The Inspector is written in ES5. How does it bypass soft field strong encapsulation? I meant, obviously, that inspectors in general can bypass encapsulation. I gave an example where weak encapsulation wins and you want to generalize it to include native-code-hosted inspectors. Nope. OK, you're assuming that the inspector can't read state from closures. It's an object inspector. So why does it matter that it can't read private fields, given that the programmer would probably have used closures if they were not using private fields? We starving startup programmers would probably have done what you wish to change the example? Nope. The constraint that the inspector be written in ES5 seems to be a purely artificial one. All of the commonly used browsers have debugger extensions. Nope, our little startup (mine, MonkeyBob's, and ReliableFred's -- plus the boss) is writing a cross-browser framework and app. No native code, let alone deoptimizing magic VM-ported code for each top JS VM. Please reply in 500 words. No, I'm not going to play your word-counting game. 876. Game over. /be ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: New private names proposal
On 2010-12-23 05:14, Brendan Eich wrote: On Dec 22, 2010, at 7:49 PM, David-Sarah Hopwood wrote: The constraint that the inspector be written in ES5 seems to be a purely artificial one. All of the commonly used browsers have debugger extensions. Nope, our little startup (mine, MonkeyBob's, and ReliableFred's -- plus the boss) is writing a cross-browser framework and app. No native code, let alone deoptimizing magic VM-ported code for each top JS VM. You don't need the debugger to be part of your framework and app, in order to use it for development. (There, concise enough this time?) -- David-Sarah Hopwood ⚥ http://davidsarah.livejournal.com signature.asc Description: OpenPGP digital signature ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: New private names proposal
On Dec 22, 2010, at 9:31 PM, David-Sarah Hopwood wrote: On 2010-12-23 05:14, Brendan Eich wrote: On Dec 22, 2010, at 7:49 PM, David-Sarah Hopwood wrote: The constraint that the inspector be written in ES5 seems to be a purely artificial one. All of the commonly used browsers have debugger extensions. Nope, our little startup (mine, MonkeyBob's, and ReliableFred's -- plus the boss) is writing a cross-browser framework and app. No native code, let alone deoptimizing magic VM-ported code for each top JS VM. You don't need the debugger to be part of your framework and app, in order to use it for development. Nope, the *inspector* (not a debugger) is a higher-level tool customized to our framework and app, written in cross-browser JS, using jQuery and whatever's hawt. Why you keep changing terms of my example is beyond me. Not your startup! (There, concise enough this time?) Yes! /be ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: New private names proposal
On 2010-12-23 05:08, Brendan Eich wrote: On Dec 22, 2010, at 7:34 PM, David-Sarah Hopwood wrote: As far as I can see, MarkM has not (at least, not on the wiki) proposed any new syntax in this discussion that had not already been proposed in one of Allen's proposals. Wrong again. Allen did not write the original strawman:names proposal. Fine, one of Allen or Dave Herman and Sam Tobin-Hochstadt's proposals. Mea culpa. Does it affect my argument at all? No. Follow that link and read http://wiki.ecmascript.org/doku.php?id=strawman:names#binding_private_names to see only examples using x.key, etc. -- no square brackets. What does the lack of an example have to do with anything? Read what it says: in the scope of 'private x', x is also bound as a plain variable to the Name value. Combined with the previous example: var name = new Name; ... obj[name] = secret; print(obj[name]); // secret it's clear that the square bracket syntax is valid in the scope of a private declaration. That is what MarkM's desugaring faithfully emulates. Perhaps that is not what the authors of the names proposal intended. If so, how was MarkM supposed to know that? Mark's example predates private_names and so may have worked in the old names proposal, It explicitly says that it does; there's no may here. but only via square brackets. Not via dot -- so again *not* the same syntax as what even strawman:names proposed. That page doesn't explicitly spell out the desugaring of '.', but MarkM did so later. There's clearly no conflict with the soft field semantics, which is the important thing, anyway. Never mind the private names proposal that supersedes names -- not faulting Mark for lacking clairvoyance here -- I'm faulting you for twisting the same syntax from its obvious meaning of all the same syntax to the subset that uses square brackets. Only if you're determined to misinterpret it, can http://wiki.ecmascript.org/doku.php?id=strawman:inherited_explicit_soft_fields#can_we_subsume_names be mistaken for a complete proposal of how to desugar the names syntax. It is obviously a partial outline. You seem to have problem owning up to mistakes. *I* have a problem owning up to mistakes? https://secure.wikimedia.org/wikipedia/en/wiki/Psychological_projection -- David-Sarah Hopwood ⚥ http://davidsarah.livejournal.com signature.asc Description: OpenPGP digital signature ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
some question about module loaders
I have read http://wiki.ecmascript.org/doku.php?id=strawman:module_loaders Which is src in evalScript(src : String) : any;url or source code? Can programmer eval code through ModuleLoader like eval operator? ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: New private names proposal
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? Dave - Original Message - From: David-Sarah Hopwood david-sa...@jacaranda.org To: es-discuss@mozilla.org Sent: Wed, 22 Dec 2010 22:01:39 -0800 (PST) Subject: Re: New private names proposal On 2010-12-23 05:08, Brendan Eich wrote: On Dec 22, 2010, at 7:34 PM, David-Sarah Hopwood wrote: As far as I can see, MarkM has not (at least, not on the wiki) proposed any new syntax in this discussion that had not already been proposed in one of Allen's proposals. Wrong again. Allen did not write the original strawman:names proposal. Fine, one of Allen or Dave Herman and Sam Tobin-Hochstadt's proposals. Mea culpa. Does it affect my argument at all? No. Follow that link and read http://wiki.ecmascript.org/doku.php?id=strawman:names#binding_private_names to see only examples using x.key, etc. -- no square brackets. What does the lack of an example have to do with anything? Read what it says: in the scope of 'private x', x is also bound as a plain variable to the Name value. Combined with the previous example: var name = new Name; ... obj[name] = secret; print(obj[name]); // secret it's clear that the square bracket syntax is valid in the scope of a private declaration. That is what MarkM's desugaring faithfully emulates. Perhaps that is not what the authors of the names proposal intended. If so, how was MarkM supposed to know that? Mark's example predates private_names and so may have worked in the old names proposal, It explicitly says that it does; there's no may here. but only via square brackets. Not via dot -- so again *not* the same syntax as what even strawman:names proposed. That page doesn't explicitly spell out the desugaring of '.', but MarkM did so later. There's clearly no conflict with the soft field semantics, which is the important thing, anyway. Never mind the private names proposal that supersedes names -- not faulting Mark for lacking clairvoyance here -- I'm faulting you for twisting the same syntax from its obvious meaning of all the same syntax to the subset that uses square brackets. Only if you're determined to misinterpret it, can http://wiki.ecmascript.org/doku.php?id=strawman:inherited_explicit_soft_fields#can_we_subsume_names be mistaken for a complete proposal of how to desugar the names syntax. It is obviously a partial outline. You seem to have problem owning up to mistakes. *I* have a problem owning up to mistakes? https://secure.wikimedia.org/wikipedia/en/wiki/Psychological_projection -- David-Sarah Hopwood ⚥ http://davidsarah.livejournal.com ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: New private names proposal
I would like to encourage everyone to stop arguing about whether my old syntax at http://wiki.ecmascript.org/doku.php?id=strawman:inherited_explicit_soft_fields#can_we_subsume_names was or was not a faithful adaptation of the old names syntax at http://wiki.ecmascript.org/doku.php?id=strawman:names. Names has moved beyond that old syntax and I am now concerned with the new one. My apologies for not updating my old page since then. At the top of http://wiki.ecmascript.org/doku.php?id=strawman:names_vs_soft_fields I show a soft fields desugaring for the currently proposed names syntax. Because [] is problematic for the reasons Dave and Brendan have explained, I delay the discussion of [] till http://wiki.ecmascript.org/doku.php?id=strawman:names_vs_soft_fields#accessing_private_identifiers_as_soft_field_values, where it parallels the discussion of [] in the private names proposal. There, I examine that issue a bit, mentioning that we could use the kludge on my earlier page, but also showing alternatives that some here will find less satisfying. Be sure to read to the bottom of that section. In any case, I'd like to withdraw my unqualified use of orthogonal on this thread, lest it be misunderstood as a claim that the syntax issues for private names and for soft fields are precisely identical. Please everyone, read the page where I go through parallel examples. I discuss some pros and cons each way as I go. I wrote this listings of differences before this thread started. I stand by my overall sense that the syntactic issues are still independent enough from the semantics that, with minor adjustments, any viable syntax proposal could be applied to either semantics. I still think the syntax and semantics at stake here are best discussed as separate questions, unless of course one of these non-orthogonalities actually turns out to be important. I would also like to encourage the continued exploration of alternative syntaxes, such as the sigil and @ approaches previously mentioned. Brendan, I still do not understand why you think it is illegitimate to consider private names and soft fields as alternatives. Do you really think we should provide syntactic support for both? -- Cheers, --Dr. Freeze ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: New private names proposal
On Dec 22, 2010, at 11:34 PM, Mark S. Miller wrote: Brendan, I still do not understand why you think it is illegitimate to consider private names and soft fields as alternatives. Do you really think we should provide syntactic support for both? The discussion here, including Dave's point about transposed get or set for [] being conceptually mismatched to the current [] meaning, and David-Sarah's reply about why you can't stop a third party from using your frozen object identity as the key in a weak map, have convinced me that even the frozen AST example doesn't need syntax, so much as weak maps and whatever soft fields make sense on top of them as library code. That leaves the private names proposal the lone bearer of new syntax. Cheers, --Dr. Freeze :-} /be ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: New private names proposal
On Wed, Dec 22, 2010 at 11:30 PM, Dave Herman dher...@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. -- Cheers, --MarkM ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: New private names proposal
On Wed, Dec 22, 2010 at 11:44 PM, Brendan Eich bren...@mozilla.com wrote: On Dec 22, 2010, at 11:34 PM, Mark S. Miller wrote: Brendan, I still do not understand why you think it is illegitimate to consider private names and soft fields as alternatives. Do you really think we should provide syntactic support for both? The discussion here, including Dave's point about transposed get or set for [] being conceptually mismatched to the current [] meaning, and David-Sarah's reply about why you can't stop a third party from using your frozen object identity as the key in a weak map, have convinced me that even the frozen AST example doesn't need syntax, so much as weak maps and whatever soft fields make sense on top of them as library code. I do not understand this reply. Could you expand? That leaves the private names proposal the lone bearer of new syntax. Cheers, --Dr. Freeze :-} /be -- Cheers, --MarkM ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
