Re: from ... import proposal

You can review the archives to see related/similar proposals/discussions, such as https://esdiscuss.org/topic/from-foo-import-foo. Bob On Wed, Apr 18, 2018 at 3:51 AM, devlato wrote: > Hello, > > sorry, I'm a newbie here, so maybe it's a wrong list. > What do you think about

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: from ... import proposal

Not directly addressing this, but do definitely check out the meeting notes, particularly the ones prior to May 2015 (when ES6 was released). IIRC this did come up at some point in the ES6 work, although I don't remember when/where it was in the notes. (Not a TC39 member, just an ordinary JS

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

from ... import proposal

Hello, sorry, I'm a newbie here, so maybe it's a wrong list. What do you think about the following proposal? https://github.com/devlato/proposal-from-import Kindest regards, devlato ___ es-discuss mailing list es-discuss@mozilla.org

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: [strawman] Symbol.thenable proposal

I don't see any problems with polyfills having to update, that's kinda how progress happens...On 17 Apr 2018 08:13, "T.J. Crowder" wrote:On Mon, Apr 16, 2018 at 6:36 PM, Tab Atkins Jr. wrote:>> I'm still strongly of the opinion that we messed

Re: [strawman] Symbol.thenable proposal

On Mon, Apr 16, 2018 at 6:36 PM, Tab Atkins Jr. wrote: > > I'm still strongly of the opinion that we messed this up... > Doing the reverse and letting > objects opt *out* of being treated as promise-like is probably the > most we can do at this point, unfortunately. I was

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