Re: Share a secret across ES6 specific modules, so that other modules cannot access the secret?

I think it'd be nice if there was something also easier, based only on file names or directory structure. ```js // log-foo.js import Foo from './Foo' console.log(Foo) ``` ```js // Foo.js class Foo {} export Foo for './log-foo' // or with expressions, all files in this folder export Foo for

Re: [strawman] Symbol.thenable proposal

On Fri, Apr 13, 2018 at 6:00 PM, Isiah Meadows wrote: > I can't remember where, but I recall seeing this discussed elsewhere > (maybe in the TC39 meeting notes?) and the conclusion was basically > ¯\_(ツ)_/¯. I'm not convinced myself it's actually worth the extra > symbol

Re: [strawman] Symbol.thenable proposal

I think the purpose of this proposal is to *forbid* module authors from making their Module Record namespace object thenable, since doing that causes confusion. Setting a property on the function doesn't work when the "then" is inherited but the object still wants to be non-thenable; I think that

Iterator Functions

With the ability to create iterators and convert other objects to them. Would it not make sense for them to implement most of the array style functions. These would execute lazily and only start once a call to `start` happens. (A new function as well). 

Re: [strawman] Symbol.thenable proposal

I agree with Tab that allowing developers to opt out of thenable behavior is the only recourse now, but I don't think `Symbol.thenable` is the best way to grant that power. In the case of module namespaces, since module authors cannot use `Symbol.thenable` as the name of an export, there's no way

Re: Iterator Functions

A buddy of mine has actually been working on implementing array producers/consumers as a library, and I think that's a good solution. i.e. iterators are a nice native addition that can power functionality like this in userland, and library authors can create libraries to make it easier to use in

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: Share a secret across ES6 specific modules, so that other modules cannot access the secret?

Related relevant proposal/strawman/whatever: - https://github.com/isiahmeadows/private-data-proposal - https://github.com/tc39/proposal-class-fields/issues/94 - https://github.com/zenparsing/js-classes-1.1/issues/44 And in particular in the first linked issue, I did propose an `export { ... } to

Re: Iterator Functions

I've got a proposal that kind of attacks this from a different angle: - https://github.com/isiahmeadows/lifted-pipeline-strawman It targets streams, but it can also work with iterables/iterators. In fact, combining functionality that could be exposed to streams and iterators identically was one

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