On Wed, Dec 22, 2010 at 11:44 PM, Brendan Eich 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 supp
On Wed, Dec 22, 2010 at 11:30 PM, Dave Herman 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
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
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:
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
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@moz
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.
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
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, Monke
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
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 prop
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 inspec
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
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 usi
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 bypass
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.)
>
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 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 Pet
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 ex
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
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 th
> 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]] attr
On Wed, Dec 22, 2010 at 11:56 AM, Mark S. Miller wrote:
> On Tue, Dec 21, 2010 at 2:44 PM, Allen Wirfs-Brock
> 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 t
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]]
> attribut
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 Tue, Dec 21, 2010 at 2:44 PM, Allen Wirfs-Brock
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
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 tok
> 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 convent
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 thi
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 Priv
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 a
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 evaluat
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 Per
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 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 th
>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 createP
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 fo
On Wed, Dec 22, 2010 at 3:26 PM, David Herman wrote:
>
> 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;
> }
>
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
>
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
> 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 cod
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
proposin
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-tim
43 matches
Mail list logo
