Re: EcmaScript Proposal – Private methods and fields proposals.

On 04/17/2018 05:31 PM, Sultan wrote: Do you limit classes to creating only the private fields declared in the class, or can they create arbitrarily named ones? Yes, just as you could write arbitrary named fields with the mentioned WeakMap approach, for example – [...] private[key] = value

Re: EcmaScript Proposal – Private methods and fields proposals.

Welcome. (And I know Electron has all the browser APIs. That was implied with the "combining Node and Chrome" part.) - Isiah Meadows m...@isiahmeadows.com Looking for web consulting? Or a new website? Send me an email and we can get started. www.isiahmeadows.com On Thu, Apr 19, 2018 at

Re: EcmaScript Proposal – Private methods and fields proposals.

appreciate the detailed counter-response and insight. fyi, electron is a browser. -kai > On 18 Apr 2018, at 6:46 AM, Isiah Meadows wrote: > > To expand in the first, there is some functionality they have had to expose > in the public API because people kept reading

Re: EcmaScript Proposal – Private methods and fields proposals.

>Do you limit classes to creating only the private fields declared in the class, or can they create arbitrarily named ones? Yes, just as you could write arbitrary named fields with the mentioned WeakMap approach, for example – [...] private[key] = value [...] private(this)[key] = value [...]

Re: EcmaScript Proposal – Private methods and fields proposals.

On 04/17/2018 02:26 PM, Sultan wrote: In the transpilation you created the field using "registry.set(this, {id: 0})" in the constructor.  If you then claim that any write to the field can also create it, then you get the hijacking behavior which you wrote doesn't happen. The difference

Re: EcmaScript Proposal – Private methods and fields proposals.

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

Re: EcmaScript Proposal – Private methods and fields proposals.

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

Re: EcmaScript Proposal – Private methods and fields proposals.

> In the transpilation you created the field using "registry.set(this, {id: 0})" >in the constructor. If you then claim that any write to the field can also create it, then you get the hijacking behavior which you wrote doesn't happen. The difference between class A { private id = 0 } and

Re: EcmaScript Proposal – Private methods and fields proposals.

On 04/17/2018 01:50 PM, Sultan wrote: >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. In the transpilation you created the field using registry.set(this, {id:

Re: EcmaScript Proposal – Private methods and fields proposals.

>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

Re: EcmaScript Proposal – Private methods and fields proposals.

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

Re: EcmaScript Proposal – Private methods and fields proposals.

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 wrote: > > can you give actual

Re: EcmaScript Proposal – Private methods and fields proposals.

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

Re: EcmaScript Proposal – Private methods and fields proposals.

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

Re: EcmaScript Proposal – Private methods and fields proposals.

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

Re: EcmaScript Proposal – Private methods and fields proposals.

>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

Re: EcmaScript Proposal – Private methods and fields proposals.

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) {    

Re: EcmaScript Proposal – Private methods and fields proposals.

Oops...somehow, I forgot about that... :-) - Isiah Meadows m...@isiahmeadows.com 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 wrote: >> Just an

Re: EcmaScript Proposal – Private methods and fields proposals.

> 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

Re: EcmaScript Proposal – Private methods and fields proposals.

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 m...@isiahmeadows.com Looking for web consulting? Or a new website? Send me an email and we can get

Re: EcmaScript Proposal – Private methods and fields proposals.

>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) {

Re: EcmaScript Proposal – Private methods and fields proposals.

I'd imagine that would fail the same way proxies fail on typed arrays. > On Apr 13, 2018, at 6:26 PM, Waldemar Horwat 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

Re: EcmaScript Proposal – Private methods and fields proposals.

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

Re: EcmaScript Proposal – Private methods and fields proposals.

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 wrote: > > The proposal is an explainer with regards to an

Re: EcmaScript Proposal – Private methods and fields proposals.

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"

Re: EcmaScript Proposal – Private methods and fields proposals.

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

Re: EcmaScript Proposal – Private methods and fields proposals.

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 wrote: > This

Re: EcmaScript Proposal – Private methods and fields proposals.

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