appreciate the detailed counter-response and insight. fyi, electron is a browser.
-kai > On 18 Apr 2018, at 6:46 AM, Isiah Meadows <[email protected]> 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 <[email protected] > <mailto:[email protected]>> 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 <[email protected] > <mailto:[email protected]>> 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 <[email protected] <mailto:[email protected]>> 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 <[email protected] > > <mailto:[email protected]>> > > 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 > [email protected] <mailto:[email protected]> > https://mail.mozilla.org/listinfo/es-discuss > <https://mail.mozilla.org/listinfo/es-discuss>
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
