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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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).
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
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
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
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
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
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,
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
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
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
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
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
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
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
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
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
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,
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
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
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
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
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
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
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
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
41 matches
Mail list logo
