Re: Since JSDoc seems cerebrally dead...
Hopefully (imo) people are hand-writing more docs now, rather than relying on autogenerated prose. On Mon, Oct 12, 2020 at 1:23 PM #!/JoePea wrote: > Why not? People are generating less docs now? That doesn't sound good! > > #!/JoePea > > On Mon, Aug 17, 2020 at 4:15 PM Isiah Meadows > wrote: > > > > JSDoc is not dead (far from it), people just don't frequently use > > automated docs generation tooling in the JS community. Most the actual > > use JSDoc provides nowadays is editor autocomplete hints and > > integrating with TypeScript (in cases where changing the extension > > isn't possible for whatever reason), so while it's still useful, it's > > just not used in the same places it was used previously. > > > > - > > > > Isiah Meadows > > cont...@isiahmeadows.com > > www.isiahmeadows.com > > > > On Sun, Aug 16, 2020 at 6:39 PM Michaël Rouges > wrote: > > > > > > Hi all, > > > > > > Since JSDoc seems cerebrally dead, why the TC39 doesn't make a real > documentation standard, evolving with the langage? > > > > > > Actually, a part of the JS community are exiling to TS to type > anything and the rest are just despited by the very outdated version of > JSDoc but don't want to add TS to their stack. > > > > > > IMHO, it's really urgent to have something formal to solve that > missing point of my favorite language. > > > > > > What would it take to make this dream come true, please? > > > > > > > > > Michaël Rouges - https://github.com/Lcfvs - @Lcfvs > > > ___ > > > 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 > ___ > 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
Re: Why does a JavaScript class getter for a private field fail using a Proxy?
Gotcha. So basically that tells the consumer "No, you can't use
Proxies". What I want to tell them is "Go ahead, use Proxies to your
heart's content", but I don't want to tell them to write all the
overly-complicated code required for their Proxies to work properly as
soon as I introduce a single private field within my class.
#!/JoePea
On Mon, Jul 27, 2020 at 3:33 PM Jordan Harband wrote:
>
> oh oops, i meant `if (o !== this)` not `if (o.foo !== this)` :-)
>
> On Mon, Jul 27, 2020 at 3:06 PM #!/JoePea wrote:
>>
>> > `o.foo(); // works`
>>
>> I think there is something missing from that example as that line
>> throws before it can get to the `new Proxy` line.
>>
>> #!/JoePea
>>
>> On Wed, Jul 15, 2020 at 10:47 PM Jordan Harband wrote:
>> >
>> > So can:
>> > ```jsx
>> > const o = { foo() { if (o.foo !== this) { throw 'detected'; } } };
>> > o.foo(); // works
>> > new Proxy(o, {}).foo(); // throws
>> > ```
>> >
>> > (as would a class that used a closed-over WeakMap for each "private field")
>> >
>> > Private fields do not introduce any new hazards here.
>> >
>> > On Tue, Jul 14, 2020 at 8:18 PM #!/JoePea wrote:
>> >>
>> >> > private members (safely) allow classes with internal slots.
>> >>
>> >> I'd say that they aren't safe, if they can break 3rd-party code on the
>> >> external public side.
>> >>
>> >> #!/JoePea
>> >>
>> >> On Sun, Jul 12, 2020 at 3:09 PM Michael Theriot
>> >> wrote:
>> >> >
>> >> > I assume OP wants to use proxies and private members together. They are
>> >> > not designed to be compatible.
>> >> >
>> >> > Proxies and private members are a UX goal primarily for developers.
>> >> > Proxies easily allow observation of another object or creation of
>> >> > exotic objects (e.g. Array), and private members (safely) allow classes
>> >> > with internal slots. Since they cannot be used together the issue
>> >> > exists, and the hack circumvents this by reimplementing private in a
>> >> > way that does not require private fields.
>> >> >
>> >> > On Sun, Jul 12, 2020 at 4:45 PM kai zhu wrote:
>> >> >>
>> >> >> as product-developer, can i ask what ux-objective you ultimately want
>> >> >> achieved?
>> >> >>
>> >> >> ```js
>> >> >> const sub = new Sub()
>> >> >>
>> >> >> // i'm a noob on proxies. what is this thing (with
>> >> >> proxied-private-fields) ultimately used for?
>> >> >> const proxy = new Proxy(sub, ...)
>> >> >> ```
>> >> >>
>> >> >> On Sun, Jul 12, 2020 at 4:34 PM Michael Theriot
>> >> >> wrote:
>> >> >>>
>> >> >>> This does require you to have both the key and the weakmap though, so
>> >> >>> it actually does succeed in hiding the data so long as the weakmap is
>> >> >>> out of scope. I guess the issue I can foresee is that the key could
>> >> >>> be modified after the object is created.
>> >> >>>
>> >> >>> e.g.
>> >> >>> ```js
>> >> >>> var a = new A();
>> >> >>> var key = Object.getOwnPropertySymbols(a)[0];
>> >> >>> delete a[key];
>> >> >>> a.hidden; // throws
>> >> >>> ```
>> >> >>>
>> >> >>> That itself can be guarded by just making the key undeletable. So, I
>> >> >>> guess this solution could work depending what your goals are?
>> >> >>>
>> >> >>> On Sun, Jul 12, 2020 at 4:21 PM Michael Theriot
>> >> >>> wrote:
>> >>
>> >> It nearly works, but the issue is that the key will be leaked by
>> >> `Object.getOwnPropertySymbols(new A())`, so it's not truly private.
>> >>
>> >> There have been ideas proposing "private symbols" but I am not
>> >> familiar with their issues, and I would guess with Class Fields they
>> >> are unlikely to materialize anyway.
>> >>
>> >> On Sun, Jul 12, 2020 at 2:19 PM François REMY
>> >> wrote:
>> >> >
>> >> > At the risk of pointing out the obvious:
>> >> >
>> >> >
>> >> >
>> >> > ```js
>> >> >
>> >> > const privkey = Symbol();
>> >> >
>> >> > const stores = new WeakMap();
>> >> >
>> >> >
>> >> >
>> >> > class A {
>> >> >
>> >> > [privkey] = {};
>> >> >
>> >> > constructor() {
>> >> >
>> >> > const priv = {};
>> >> >
>> >> > priv.hidden = Math.random();
>> >> >
>> >> > stores.set(this[privkey], priv);
>> >> >
>> >> > }
>> >> >
>> >> >
>> >> >
>> >> > get hidden() {
>> >> >
>> >> > const priv = stores.get(this[privkey]);
>> >> >
>> >> > return priv.hidden;
>> >> >
>> >> > }
>> >> >
>> >> > }
>> >> >
>> >> >
>> >> >
>> >> > var as = [
>> >> >
>> >> > new A(),
>> >> >
>> >> > new Proxy(new A(),{}),
>> >> >
>> >> > new Proxy(new A(),{}),
>> >> >
>> >> > ];
>> >> >
>> >> > console.log(as.map(a=>a.hidden));
>> >> >
>> >> > ```
>> >> >
>> >> >
>> >> >
>> >> >
>> >> >
>> >> >
>> >> >
>> >> > From: Michael Theriot
>> >> > Sent: Sunday, July 12, 2020 20:59
>>
Re: Private fields in sub-objects within class definition.
Sure, but I'm first curious about classes because in my example, the
code is all defined _inside_ a class definition's lexical scope, where
private fields (or keys) are _currently_ defined to exist, so it seems
like an approach we can currently take.
Private fields on objects without classes being in play would be neat too!
#!/JoePea
On Sun, Aug 9, 2020 at 7:55 PM Michael Theriot
wrote:
>
> Why stop at class definitions?
>
> e.g.
> ```js
> let obj;
> {
> let local = 0;
> obj = {
> get local() {
> return local;
> }
> }
> }
> ```
>
> becomes
> ```js
> const obj = {
> #local: 0,
> get local() {
> return this.#local;
> }
> }
> ```
>
> On Fri, Aug 7, 2020 at 3:33 PM #!/JoePea wrote:
>>
>> Not sure if the following is exactly how we'd want it to be, but it
>> would be useful:
>>
>> ```js
>> class Foo {
>> // calculatedValue is intended to have read-only properties
>> calculatedValue = {
>> #x: 0,
>> get x() { return this.#x },
>> #y: 0,
>> get y() { return this.#y },
>> #z: 0,
>> get z() { return this.#z },
>> }
>>
>> update() {
>> this.calculatedValue.#x = 42 // ok
>> this.calculatedValue.#y = 42 // ok
>> this.calculatedValue.#z = 42 // ok
>> }
>> }
>> ```
>>
>> End user:
>>
>> ```js
>> const foo = new Foo
>> foo.calculatedValue.x // ok
>> foo.calculatedValue.#x // syntax error
>> ```
>>
>> We could currently do something like this:
>>
>> ```js
>> class Foo {
>> #calcX = 0
>> #calcY = 0
>> #calcZ = 0
>>
>> // calculatedValue is intended to have read-only properties
>> calculatedValue = (() => {
>> const self = this
>> return {
>> get x() { return self.#calcX },
>> get y() { return self.#calcY },
>> get z() { return self.#calcZ },
>> }
>> })()
>>
>> update() {
>> this.#calcX = 42 // ok
>> this.#calcY = 42 // ok
>> this.#calcZ = 42 // ok
>> }
>> }
>> ```
>>
>> Any plans for something like this? Is there a plan for private fields
>> for object literals? If so, maybe that can somehow tie into usage
>> within class bodies with WeakMap-ish semantics.
>>
>> #!/JoePea
>> ___
>> 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
Re: Since JSDoc seems cerebrally dead...
Why not? People are generating less docs now? That doesn't sound good! #!/JoePea On Mon, Aug 17, 2020 at 4:15 PM Isiah Meadows wrote: > > JSDoc is not dead (far from it), people just don't frequently use > automated docs generation tooling in the JS community. Most the actual > use JSDoc provides nowadays is editor autocomplete hints and > integrating with TypeScript (in cases where changing the extension > isn't possible for whatever reason), so while it's still useful, it's > just not used in the same places it was used previously. > > - > > Isiah Meadows > cont...@isiahmeadows.com > www.isiahmeadows.com > > On Sun, Aug 16, 2020 at 6:39 PM Michaël Rouges > wrote: > > > > Hi all, > > > > Since JSDoc seems cerebrally dead, why the TC39 doesn't make a real > > documentation standard, evolving with the langage? > > > > Actually, a part of the JS community are exiling to TS to type anything > > and the rest are just despited by the very outdated version of JSDoc but > > don't want to add TS to their stack. > > > > IMHO, it's really urgent to have something formal to solve that missing > > point of my favorite language. > > > > What would it take to make this dream come true, please? > > > > > > Michaël Rouges - https://github.com/Lcfvs - @Lcfvs > > ___ > > 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 ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Re: Are ES6 modules in browsers going to get loaded level-by-level?
Right, exactly. So naively sending all dependencies wastefully is just the first step. > Afaik the more promising path are prefetch hints on the client. E.g. the client (or initial HTML payload) knows the dependency tree, adds tags for preloading the required modules, and then the browser can properly handle fine-grained caching from there, only requesting what is actually needed. That may be nice, but I imagine people importing libraries from different domains (without knowing the graphs, for example, in simple codepen or jsfiddle demos with no build tooling). So suppose the client code consists only of one single line of HTML, just ```html
Re: Re: Are ES6 modules in browsers going to get loaded level-by-level?
> If I understand HTTP/2 correctly, this requires more than a server > that simply has HTTP push, it requires a server that understands how > to read ES modules and enumerate their dependencies. Not only that: The server also has to "know" which modules are already cached by the client (including potential match/modified-since logic). If the server always sends _all_ modules in the dependency graph, then it's just a less efficient bundle of all modules. Afaik the more promising path are prefetch hints on the client. E.g. the client (or initial HTML payload) knows the dependency tree, adds tags for preloading the required modules, and then the browser can properly handle fine-grained caching from there, only requesting what is actually needed. Cheers, Jan On Mon, Oct 12, 2020 at 12:59 PM #!/JoePea wrote: > I'm asking about a server that, upon request of a `.js` file, knows > how to enumerate the dependency tree based on that file, _then_ HTTP > pushes all the modules at once. > > So basically, from the code > > ```html >
Re: Re: Are ES6 modules in browsers going to get loaded level-by-level?
I'm asking about a server that, upon request of a `.js` file, knows how to enumerate the dependency tree based on that file, _then_ HTTP pushes all the modules at once. So basically, from the code ```html
nested import statements
Why isn't it a thing yet? - http://www.petecorey.com/blog/2016/07/17/meteors-nested-import-controversy/ - https://github.com/benjamn/reify/blob/master/WHY_NEST_IMPORTS.md At runtime they'd be similar to `await`ing an `import` statement. Maybe a requirement should be that nested (statically-analyzable) imports should appear only within `async` functions (so they operate the same as `await import()`). Is there something bad about the idea that isn't described in those writings? #!/JoePea ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
