Re: EcmaScript Proposal – Private methods and fields proposals.

kai zhu kaizhu256 at gmail.com
Fri Apr 20 01:37:08 UTC 2018


appreciate the detailed counter-response and insight.  fyi, electron is a browser.

-kai

> On 18 Apr 2018, at 6:46 AM, Isiah Meadows <isiahmeadows at gmail.com> wrote:
> 
> To expand in the first, there is some functionality they have had to expose in the public API because people kept reading properties on those two internal stream properties.
> 
> Similarly, jQuery has had in the past people relying so much on bugs that they had to turn some of them into features and document them in the source code. It was specifically because so many of these cases were propping up in the source code that they had to fork a new version (2.0) to fix all these bugs without breaking everyone. They also created jQuery Migrate just to help consumers migrate between patches, to notify people of certain bug fixes and minor changes that would otherwise break quite a few people's existing code bases.
> 
> Or, in summary, as a library author, if you expose it, even if you don't document it, or even if you specifically warn people to not rely on it, people *will* inevitably find ways to depend on it, making some forms of bug fixes or other improvements practically impossible. In fact, this similar concern is why Python introduced its name mangling convention for `self.__foo` private variables - people clashing and/or otherwise relying of private data. For what it's worth, soft private (accessible via reflection, like Java, Ruby, etc.) is sufficient if you don't support subclassing, but it's when you do, that's where you need hard privacy (like C++, etc.).
> 
> And don't forget: not all projects are particularly small, not all JS is simple glue code, and non-browser use cases aren't even obscure. (Slack for desktop is based on Electron, a platform combining Node and Chrome, and both PayPal's and Ebay's entire production backends use Node. Oh, and even NASA has picked it up for a few things on Earth, primarily for data processing at scale.) So if you're going to continue to blast and ignore it, please do your research first and realize they have unique needs themselves.
> 
> On Tue, Apr 17, 2018, 18:12 Isiah Meadows <isiahmeadows at gmail.com <mailto:isiahmeadows at gmail.com>> wrote:
> If you don't need them, don't use them. The use for them is three-fold:
> 
> 1. Not trusting people to avoid relying on API implementation details (think: Node.js `_readableStream`/`_writableStream` used so frequently out of core they've ran into issues updating it even in patch releases).
> 2. In the face of inheritance, avoiding name collision. (This is a big one at scale, not so much in a 30k web app.)
> 3. Giving engines the ability to better structure object allocation and property access. This is *very* useful for perf critical scenarios.
> 
> Finally, if you don't need them, don't use them. But keep in mind, there is a use case and a need. 
> 
> On Tue, Apr 17, 2018, 02:17 kai zhu <kaizhu256 at gmail.com <mailto:kaizhu256 at gmail.com>> 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]
>   }
> }
> ```
> 
> 
> On 4/17/18, Sultan <thysultan at gmail.com <mailto:thysultan at gmail.com>> 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 <waldemar at google.com <mailto: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
> >>
> >
> _______________________________________________
> es-discuss mailing list
> es-discuss at mozilla.org <mailto:es-discuss at mozilla.org>
> https://mail.mozilla.org/listinfo/es-discuss <https://mail.mozilla.org/listinfo/es-discuss>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20180420/f31f017d/attachment-0001.html>


More information about the es-discuss mailing list