You're almost right about that. The guardian logic that ensures this cannot
happen is that the `[[DeclarationInfo]]` of the instance whose private
fields are being accessed must either be or be a prototype of the
`[[DeclarationInfo]]` of the current function. This was part of the update
I made to the proposal last night after replying to Waldemar. The only way
for this to be true is that the current function would have been declared
within the same declaration scope as the function used to create the
instance. When this match doesn't occur, use of the `#` operator causes a
TypeError.
On Sat, Jul 28, 2018 at 1:47 AM Jordan Harband <ljh...@gmail.com> wrote:
> If the "name" is just a string, though, then it's just another global
> namespace. I could access a private field named "id" on every object that
> had one, in a try/catch, and i'd be able to not just observe if an object
> has an "id" private field, but access or alter its contents.
>
> On Fri, Jul 27, 2018 at 9:37 PM, Ranando King <king...@gmail.com> wrote:
>
>> > The proposal commingles static and instance private properties. In
>> the first example, you could read or write this#.field2, and it would
>> work. How would you encode the generic expression a#.[b]?
>>
>> That's not quite right. I added some details about how all this works a
>> few hours after you wrote this message. Here's the gist:
>> The `static` keyword would cause `field2` to be placed in the
>> `[[PrivateValues]]` record of the function. The `protected` keyword would
>> cause a key/value pair resembling `"field2": Symbol("field2")` to be placed
>> in the `[[DeclarationInfo]]` record of the function. Since you used `this`,
>> I will assume it is an instance of `ExampleFn`. The expression
>> `this#.field2` within `ExampleFn` would translate into
>>
>> `this.[[PrivateValues]][this.[[DeclarationInfo]].field2] ->
>> this.[[PrivateValues]][undefined] -> TypeError`
>>
>> assuming that the prototype of `ExampleFn` contained no definition for
>> field2. Since the `static` field belongs to the function it is declared in,
>> it can only be accessed via the function object itself, i.e.
>> `ExampleFn#.field2` or `this.constructor#.field2` or the array-notation
>> equivalents. I can't say that I'm understanding what you're looking for
>> with `a#.[b]` That looks like a syntax error to me. If you're trying to
>> understand how `a#[b]` works, it would be exactly the same. The best way to
>> understand how it works is to look at this equation for the `#` operator.
>>
>> <lParam>#<rParam> ===
>> <lParam>.[[PrivateValues]][<lParam>.[[DeclarationInfo]]<rParam>]
>>
>> In the case of `a#[b]`, the result would be:
>>
>> a.[[PrivateValues]][a.[[DeclarationInfo]] [b] ]
>>
>> I get that all the square braces can make that hard to read, so here's
>> the step by step:
>>
>> 1. Throw a type error if a is not an object
>> 2. Let D be the [[DeclarationInfo]] record of object.
>> 3. if D is not in the lexical scope chain of the current function,
>> throw a TypeError
>> 4. Let N be the value for the key matching b in D, or undefined if no
>> such key exists.
>> 5. Let P be the [[PrivateValues]] record of object a
>> 6. If N is not a key of P, Throw a TypeError
>> 7. return P[N]
>>
>> > Worse, the proposal commingles all private properties across all
>> classes. There's nothing in the proposed code stopping you from reading
>> and writing private properties defined by class A on instances of an
>> unrelated class B.
>>
>> That's not right either. The example desugaring does indeed throw all
>> maps into the same WeakMap. I'll work on that to make a better example.
>> However, to get a better understanding of how I see the implementation, you
>> should read the implementation details section. There's a much better
>> description there. Besides, the 7 step description I just wrote for you
>> should help you realize that:
>>
>> - If the function you're in doesn't know the names of the private
>> fields of your object, you get a TypeError.
>> - If the object you're accessing doesn't recognize the name of the
>> field you're trying to access, you get a TypeError.
>>
>> So there really is no way to apply the private field names of `class A`
>> onto an instance of `class B`.
>>
>> I'll spend some time tonight re-tooling my example desugaring and a few
>> other details I thought of while writing this in the proposal. Hopefully,
>> that'll prevent more confusion.
>>
>>
>> On Fri, Jul 27, 2018 at 7:55 PM Waldemar Horwat <walde...@google.com>
>> wrote:
>>
>>> On 07/26/2018 01:55 PM, Ranando King wrote:
>>> > I've just finished updating my proposal with an [Existing proposals](
>>> https://github.com/rdking/proposal-object-members/blob/master/README.md#existing-proposals)
>>> section that lists the major differences.
>>>
>>> Reading the proposal, I'm not yet sure what it's supposed to do. Some
>>> things I've noticed:
>>>
>>> - The proposal commingles static and instance private properties. In
>>> the first example, you could read or write this#.field2, and it would
>>> work. How would you encode the generic expression a#.[b]?
>>>
>>> - Worse, the proposal commingles all private properties across all
>>> classes. There's nothing in the proposed code stopping you from reading
>>> and writing private properties defined by class A on instances of an
>>> unrelated class B.
>>>
>>> Waldemar
>>>
>>
>> _______________________________________________
>> 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
