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 <isiahmead...@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 <kaizhu...@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 <thysul...@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 <walde...@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@mozilla.org
>> https://mail.mozilla.org/listinfo/es-discuss
>>
>
_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
