Re: EcmaScript Proposal – Private methods and fields proposals.

[Sultan]

>An instance has a fixed set of private fields which get created at object
creation time.

The implications of this alternative does not necessarily limit the
creation of private fields to creation time, for example writing to a
private field in the constructor or at any arbitrary time within the
lifecycle of the instance.

class HashTable {
  constructor() {
    private[Symbol.for('length')] = 0
  }
  set(key, value) {
    private[key] = value
  }
  get(key) {
    return private[key]
  }
}

>How do you deal with inner nested classes wanting to refer to outer
classes' private fields?

Not sure i understood what you mean by this?


On Tue, Apr 17, 2018 at 1:43 AM, Waldemar Horwat <waldemar at google.com>
wrote:

> On 04/13/2018 09:41 PM, Sultan wrote:
>
>>  >Writing your private field to an object that's not an instance of your
>> class.
>>  >and then invoking the above write method with a this value that's not
>> an instance of A, such as a proxy.
>>
>> Given:
>>
>> class A {
>>    private id = 0;
>>    private method(value) {
>>      return value;
>>    }
>>    write(value) {
>>      private(this)["id"] = private["method"](value);
>>    }
>> }
>>
>> I imagine this means trying to do something along the lines of:
>>
>> (new A()).write.call({}, 'pawned');
>>
>> This would fail. The private syntax call site would be scoped to the
>> provider class. For example imagine the current possible transpilation of
>> this:
>>
>> ;(function (){
>>    var registry = WeakMap();
>>
>>    function A () {
>>      registry.set(this, {id: 0})
>>    }
>>    A.prototype.write: function () {
>>      registry.get(this)["id"] = registry.get(this.constructor)["method"].call(this,
>> value);
>>    }
>>
>>    // shared(i.e private methods)
>>    registry.set(A, {
>>      method: function (value) {
>>        return value;
>>      }
>>    });
>>
>>    return A
>> })();
>>
>> Trying to do the the afore-mentioned forge here would currently fail
>> along the lines of cannot read property "id" of  "undefined".
>>
>
> OK, so that aspect of the proposal looks the same as the existing private
> proposals — an instance has a fixed set of private fields which get created
> at object creation time.  There are tricky additional wrinkles when it
> comes to inheritance, but you can look them up in the existing proposals.
>
> Are the only significant changes the different property naming syntax and
> that you provide a way to map strings to private slots?  How do you deal
> with inner nested classes wanting to refer to outer classes' private fields?
>
>     Waldemar
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20180417/722a67d4/attachment-0001.html>