Re: Proposal: Forced Chaining Operator "!."

[Ben Wiley]

Sorry to show up late but just wanted to point out that shipping this
feature with the ! symbol would break TypeScript, which has this operator
but only at compile time for forcing the compiler to believe that a
nullable value will be non-null at the time of execution (assuming you have
some information the compiler doesn't). It has no runtime effect of
creating objects.

Le mar. 5 mai 2020 07 h 36, Tobias Buschor  a
écrit :

> I think that would work, but the many nested brackets bother me.
>
> Am Mo., 27. Apr. 2020 um 14:23 Uhr schrieb Naveen Chawla <
> naveen.c...@gmail.com>:
>
>> Can someone confirm if the following nullish coalescing assignment
>> operator proposal example would work for this, or would it produce some
>> other kind of result?:
>>
>> ```js
>> (((table ??= {}).user ??= {}).id ??= {}).type = 'int'
>> ```
>> Regardless, I'm not a TC39 member but I would definitely be against
>> forcing a type during assignment if "not already that type", as recommended
>> in the original post. I think this could be a source of serious bugs in
>> particular when an existing type structure has been miscalculated by the
>> person using that "force type" operator. So regardless, I would prefer any
>> shorthand to only assign to object/array etc. "if nullish". This would
>> raise errors if already of an unexpected type, but I would much prefer that
>> over forcing a new structure where an existing one already exists (and
>> overwriting data).
>>
>> On Mon, 27 Apr 2020 at 10:17, Max Fechner  wrote:
>>
>>> How about something like
>>>
>>>
>>>
>>> table{}.user{}.id{}.type = ‘int’
>>>
>>>
>>>
>>> this syntax could be used for arrays, too:
>>>
>>>
>>>
>>> table{}.userList[].push(‘Jane Doe’)
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> *From: *es-discuss  on behalf of Jacob
>>> Bloom 
>>> *Date: *Monday, 27April, 2020 at 02:23
>>> *To: *es-discuss 
>>> *Subject: *Re: Proposal: Forced Chaining Operator "!."
>>>
>>>
>>>
>>> (Sorry for the triple-post, I keep pondering this proposal) Come to
>>> think of it, you could do something pretty similar with the `??=` operator
>>> from the logical assignments proposal:
>>>
>>>
>>>
>>> ```javascript
>>>
>>> (((table ??= {}).user ??= {}).id ??= {}).type = 'int';
>>>
>>> ```
>>>
>>>
>>>
>>> The main difference being that it tests for nullishness instead of
>>> whether the LHS is a non-null object, but I think that's within the spirit
>>> of the original proposal. It also lets you set a custom default value (like
>>> the "getsert" function above). The shortfall of course is the accumulating
>>> parentheses
>>>
>>>
>>>
>>> On Sat, Apr 25, 2020 at 8:08 PM Jacob Bloom 
>>> wrote:
>>>
>>> Is the Perl syntax opt-in like the proposed operator? Or does it happen
>>> on all accesses to nulls? If it's opt-in in JS, then it doesn't seem to me
>>> that it'd cause too much unexpected behavior, though it could be argued
>>> that it's ripe for abuse by new devs trying to avoid errors.
>>>
>>>
>>>
>>> Something that might be a more generalized middle ground (and could
>>> later assist in transpiling the !. operator) is a "getsert" (?) method in
>>> the standard library that takes a default value and sets it on the parent
>>> object if that property is currently unset:
>>>
>>>
>>>
>>> ```javascript
>>>
>>> Object.getsert = (obj, identifier, defaultvalue) => {
>>>   if (!(identifier in obj)) obj[identifier] = defaultvalue;
>>>   return obj[identifier];
>>> }
>>>
>>> const table = {};
>>> console.log('before getsert:', table.user); // undefined
>>> console.log('during getsert:', Object.getsert(table, 'user', 5)); // 5
>>> console.log('after getsert:', table.user); // 5
>>>
>>> ```
>>>
>>>
>>>
>>> ...I have concerns about such a method's usability though, since a
>>> getsert is far more verbose than a normal get. It'd be more convenient on
>>> Object.prototype (e.g. `table.getsert('user', 5)` ), but I assume that's a
>>> no-go.
>>>
>>>
>>>
>>> Oh also, I think the proposed syntax would collide with
>>> TypeScript's non-null assertion operator
>>> https://www.typescriptlang.org/docs/handbook/release-notes/typescript-2-0.html#non-null-assertion-operator
>>>  --
>>> I don't know to what degree that's a concern when proposing new JS syntax
>>>
>>>
>>>
>>> On Sat, Apr 25, 2020 at 3:00 PM Joe Eagar  wrote:
>>>
>>>
>>>
>>> Anyone have ideas on more examples? It’s tempting to make a transpiler
>>> plugin to see how it works in practice, but I’d like to see more examples
>>> first. Thanks
>>>
>>>
>>>
>>> On Sat, Apr 25, 2020 at 1:12 PM Jacob Bloom 
>>> wrote:
>>>
>>> Maybe it would be less footgunny to support autovivification in a more
>>> class-based way, like Python does?
>>>
>>>
>>>
>>> ```javascript
>>>
>>> class AutoVivArray extends Array {
>>>   [Symbol.getMissing](identifier) {
>>> /* if we're here, identifier is not an ownProperty
>>>  * and is nowhere on the prototype chain */
>>> this[identifier] = new Whatever();
>>> return this[identifier];
>>>   }
>>> }
>>>
>>> ```
>>>
>>>
>>>
>>> Though I 

Re: Double wildcard "re-exports"... off-limits forever?

[Ben Wiley]

Augusto,

I think the rest import/export could be an interesting idea although it
doesn't quite solve my case since I would like to keep the original names
and treat one API as an override of the other (in your case it seems you're
trying to combine all exports from multiple libraries by changing names in
some cases). The rest export would also still require explicitly naming the
duplicate re-exports, which means redundant export declarations.

I did consider something very similar (like rest imports) while I was
trying to arrive at a solution though. It's a cool idea for sure!

Something that could avoid the dangerous situation that necessitated the
duplicate re-export rule in the first place, would be to have some kind of
"joint import/export" syntax designed for this use case, where multiple
import sources are accepted.

e.g.

```js
// api-base.js
export { Foo, ApiError };

// api-derived.js
export { Bar, ApiError };

// index.js
export * from './api-base.js', './api-derived.js';
// or...
import * as api from './api-base.js', './api-derived.js';
```

This way you're explicitly stating your intent for exports from the first
source to be override-able by those from the second source. Semantically,
at a high level you can think of this as having behavior similar to
Object.assign or an object rest spread, where first a set of exports is
formed from the first source, then the second set of exports is grafted on
top, possibly overriding some values, then a potential third source, and so
on.

Various implementations could be considered, including reading the exports
from right-to-left to avoid registering the same export name twice
(although I'd guess the http requests wouldn't be fired until all export
paths are determined anyway, so might not make a meaningful difference).

Ben

On Fri, Feb 14, 2020 at 12:47 PM Augusto Moura 
wrote:

> If I understand it correctly, I had a similar problem with generated apis
> from OpenApi, two apis have a error definition with the name ApiError, i
> want to reexport all classes (a lot of model definitions) from both apis.
> The problem is that using `export * from 'api-a'; export * from 'api-b';`
> raises a error that ApiError is a duplicated name. So I have 2 options, or
> I reexport all definitions from the apis explicitly (hundreds of `export {
> Foo } from 'api-b'`) just to rename the ApiError to ApiAError at then end
> or I don't rexport then together at all (splitting the reexports in 2 files
> and having the dev to import the necessary models from the different files).
>
> If we could have a rest-operator like construct for imports the problem
> would be solved, something like:
> ```js
> // api-a.js
> export { Foo, ApiError };
>
> // api-b.js
> export { Bar, ApiError };
>
> // apis.js
> export { ApiError as ApiAError, * } from './api-a.js'; // exporting Foo
> and ApiAError
> export { ApiError as ApiBError, * } from './api-b.js'; // exporting Bar
> and ApiBError
>
> // other ideas for syntax
> export { ApiError as  ApiAError }, * from './api-a.js'; // similiar to
> default and named imports
> export { ApiError as  ApiAError, ... } from './api-a.js'; // similar to
> spread syntax
> export { ApiError as  ApiAError, ...* } from './api-a.js'; // mix from
> spread syntax and wild card imports
> // this last is one is the one I like the most, because both wildcards and
> spread are already familiar in the language, and it reads like "import the
> rest and rexport as it is"
> ```
>
> Em sex., 14 de fev. de 2020 às 01:02, Ben Wiley 
> escreveu:
>
>> Apologies if this has already been talked about at length at some point.
>> I was unable to find much in the way of relevant discussions.
>>
>> I found a compelling use case for something which seems to be off-limits
>> in the JavaScript language, that is wildcard re-exporting where the same
>> export name appears in multiple of the export-forwarded imports.
>>
>> e.g.
>> ```
>> // a.js
>> export const a = 1;
>>
>> // b.js
>> export const b = 2;
>>
>> // c.js
>> export * from './a.js';
>> export * from './b.js';
>> ```
>>
>> The ideal use case would be shipping an "override library" that ships all
>> the default exports of an upstream library, except it replaces some of them
>> with its own overrides. The object-oriented folks might think of it like a
>> derived class. This can of course be accomplished alternatively by
>> exporting an object which merges all the named exports from each library,
>> but the major disadvantage I see is that we would no longer have access to
>> tree-shaking, since that object contains *all* of the exports. For a really
>> big upstream library, that could make a large difference in kiloby

Re: Double wildcard "re-exports"... off-limits forever?

[Ben Wiley]

@Jordan: yes that also works, but for a less trivial example that is
annoying to maintain. I prefer to narrow in sources of truth where
possible. But yes that would satisfy the app user requirements, just make
the library dev's job more annoying.

@Guy: no unintentional sorry. The intent was to show an actual override. :)

Le ven. 14 févr. 2020 04 h 17, Guy Bedford  a écrit :

> Did you mean to have both examples use ‘export const a = 1’?
>
> This ambiguous export case is supposed to be an explicit error from the
> spec. If the export is being stripped and not throwing an error sounds like
> a possible browser bug.
>
> On Fri, Feb 14, 2020 at 09:09 Jordan Harband  wrote:
>
>> Wouldn't the solution be, don't use `import * as`, but instead,
>> explicitly import and re-export what you want?
>>
>> On Thu, Feb 13, 2020 at 8:02 PM Ben Wiley 
>> wrote:
>>
>>> Apologies if this has already been talked about at length at some point.
>>> I was unable to find much in the way of relevant discussions.
>>>
>>> I found a compelling use case for something which seems to be off-limits
>>> in the JavaScript language, that is wildcard re-exporting where the same
>>> export name appears in multiple of the export-forwarded imports.
>>>
>>> e.g.
>>> ```
>>> // a.js
>>> export const a = 1;
>>>
>>> // b.js
>>> export const b = 2;
>>>
>>> // c.js
>>> export * from './a.js';
>>> export * from './b.js';
>>> ```
>>>
>>> The ideal use case would be shipping an "override library" that ships
>>> all the default exports of an upstream library, except it replaces some of
>>> them with its own overrides. The object-oriented folks might think of it
>>> like a derived class. This can of course be accomplished alternatively by
>>> exporting an object which merges all the named exports from each library,
>>> but the major disadvantage I see is that we would no longer have access to
>>> tree-shaking, since that object contains *all* of the exports. For a really
>>> big upstream library, that could make a large difference in kilobytes
>>> shipped to the browser. So preserving the named exports is desirable.
>>>
>>> The protections against double-re-exporting vary. In Chrome and Firefox,
>>> there are no runtime errors but the duplicated exports will be stripped and
>>> unavailable. If you try Babel or Typescript, the compiler will throw an
>>> error.
>>>
>>> I understand *not* protecting against this could lead to very weird
>>> debugging situations for unwitting users who didn't realize their wanted
>>> import was being overwritten, however I'd love if there were a way to say
>>> "I know what I'm doing, don't stop me." As far as I can immediately tell
>>> nothing about ES imports would prevent the compiler from being able to know
>>> the order of precedence for overridden exports, and the "ambiguity" would
>>> be mainly from the perspective of an unwitting user. I recognize that
>>> import trees may be processed in parallel, however since code execution is
>>> delayed until the import tree is complete I would think we could resolve
>>> any ambiguities by that time. However it's possible I missed something -
>>> maybe there's a case related to circular imports which ruins this?
>>>
>>> Anyway, I wrote up some more detailed thoughts on this problem, and some
>>> demo code, here:
>>> https://github.com/benwiley4000/wildcard-export-override-example
>>>
>>> Ben
>>> ___
>>> 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

Double wildcard "re-exports"... off-limits forever?

[Ben Wiley]

Apologies if this has already been talked about at length at some point. I
was unable to find much in the way of relevant discussions.

I found a compelling use case for something which seems to be off-limits in
the JavaScript language, that is wildcard re-exporting where the same
export name appears in multiple of the export-forwarded imports.

e.g.
```
// a.js
export const a = 1;

// b.js
export const b = 2;

// c.js
export * from './a.js';
export * from './b.js';
```

The ideal use case would be shipping an "override library" that ships all
the default exports of an upstream library, except it replaces some of them
with its own overrides. The object-oriented folks might think of it like a
derived class. This can of course be accomplished alternatively by
exporting an object which merges all the named exports from each library,
but the major disadvantage I see is that we would no longer have access to
tree-shaking, since that object contains *all* of the exports. For a really
big upstream library, that could make a large difference in kilobytes
shipped to the browser. So preserving the named exports is desirable.

The protections against double-re-exporting vary. In Chrome and Firefox,
there are no runtime errors but the duplicated exports will be stripped and
unavailable. If you try Babel or Typescript, the compiler will throw an
error.

I understand *not* protecting against this could lead to very weird
debugging situations for unwitting users who didn't realize their wanted
import was being overwritten, however I'd love if there were a way to say
"I know what I'm doing, don't stop me." As far as I can immediately tell
nothing about ES imports would prevent the compiler from being able to know
the order of precedence for overridden exports, and the "ambiguity" would
be mainly from the perspective of an unwitting user. I recognize that
import trees may be processed in parallel, however since code execution is
delayed until the import tree is complete I would think we could resolve
any ambiguities by that time. However it's possible I missed something -
maybe there's a case related to circular imports which ruins this?

Anyway, I wrote up some more detailed thoughts on this problem, and some
demo code, here:
https://github.com/benwiley4000/wildcard-export-override-example

Ben
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Re: Proposal For A New Alternative Keyword To “this” For Classes

[Ben Wiley]

Whatever the implementation, I'd be surprised to learn that the browser
*does* have the information automatically and wouldn't need to store
additional memory similar to .bind().

But I'm also not a browser engine expert, so there's that.

Le lun. 11 mars 2019 11 h 55, john larson  a
écrit :

> Well, actually this is the same discussion we had with *@Jordan Harband. *I
> think the js run-time already has that information at hand, so as long as
> we don't implement this as pure syntactical sugar, there would not be a
> need to keep an extra reference to anything, because it would be already
> there. The run-time will know which instance the invoked method belongs
> to. But as I said, it would be insightful to get a js engine expert opinion
> on this. Having said that, I believe it is just an implementation detail
> and can be handled one way or the other. I guess the “class property
> arrow methods in React" example you just provided also supports this
> notion.
>
> On Mon, Mar 11, 2019 at 6:23 PM Ben Wiley 
> wrote:
>
>> The main issue here is that you're sort of asking for something too late.
>>
>> If you reference the "notThis" keyword inside a callback method that has
>> been separated from "its own" class instance, you're now saying "could you
>> please do this all in the context of your instance", but your method
>> doesn't know what its instance is because it never saved a reference.
>>
>> Alternatively the compiler would notice that the "notThis" keyword is
>> invoked inside a method, and automatically make a bound property on
>> construction. The problem is that you're eagerly making a copy of every
>> method using "notThis" for every instance that exists - eating up a whole
>> bunch of extra memory for large collections - without knowing necessarily
>> that those bound copies will be used. Granted, we're triggering the same
>> problem when folks are using "class property arrow methods" for all their
>> methods in React classes.
>>
>> Ben
>>
>> Le lun. 11 mars 2019 11 h 04, john larson  a
>> écrit :
>>
>>> *@Rob:* Thanks for pointing out "proposal-bind-operator". I examined
>>> the proposal and as far as I understand, it is just another way to create a
>>> bound enclosing function. What I am proposing is just the opposite, no
>>> binding should take place in the enclosing function. A method call or usage
>>> of a property should already have its lexical scope pointing to the class
>>> instance and should not need any binding of its enclosing environment to
>>> function correctly.
>>>
>>> On Mon, Mar 11, 2019 at 4:57 PM Rob Ede  wrote:
>>>
>>>> I would imagine that this can be achieved with bind operator proposal,
>>>> which already has Babel support, despite no examples showing usage inside a
>>>> class.
>>>>
>>>> Something like:
>>>> `oReq.addEventListener("load", ::this.responseHandler);`
>>>> seems to be the syntax that will de-sugar to
>>>> `oReq.addEventListener("load", this.responseHandler.bind(this));`
>>>> to get you the desired this binding.
>>>>
>>>> I’m surprised this idea hasn't been mentioned yet although things have
>>>> been moving slowly on that proposal and it seems to need some community
>>>> support to move along.
>>>>
>>>> Regards,
>>>> Rob
>>>>
>>>>
>>>> References:
>>>> 1: Bind Syntax Proposal (https://github.com/tc39/proposal-bind-operator
>>>> )
>>>> 2: Babel Plugin (
>>>> https://babeljs.io/docs/en/next/babel-plugin-proposal-function-bind)
>>>>
>>>> ___
>>> 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: Proposal For A New Alternative Keyword To “this” For Classes

[Ben Wiley]

The main issue here is that you're sort of asking for something too late.

If you reference the "notThis" keyword inside a callback method that has
been separated from "its own" class instance, you're now saying "could you
please do this all in the context of your instance", but your method
doesn't know what its instance is because it never saved a reference.

Alternatively the compiler would notice that the "notThis" keyword is
invoked inside a method, and automatically make a bound property on
construction. The problem is that you're eagerly making a copy of every
method using "notThis" for every instance that exists - eating up a whole
bunch of extra memory for large collections - without knowing necessarily
that those bound copies will be used. Granted, we're triggering the same
problem when folks are using "class property arrow methods" for all their
methods in React classes.

Ben

Le lun. 11 mars 2019 11 h 04, john larson  a
écrit :

> *@Rob:* Thanks for pointing out "proposal-bind-operator". I examined the
> proposal and as far as I understand, it is just another way to create a
> bound enclosing function. What I am proposing is just the opposite, no
> binding should take place in the enclosing function. A method call or usage
> of a property should already have its lexical scope pointing to the class
> instance and should not need any binding of its enclosing environment to
> function correctly.
>
> On Mon, Mar 11, 2019 at 4:57 PM Rob Ede  wrote:
>
>> I would imagine that this can be achieved with bind operator proposal,
>> which already has Babel support, despite no examples showing usage inside a
>> class.
>>
>> Something like:
>> `oReq.addEventListener("load", ::this.responseHandler);`
>> seems to be the syntax that will de-sugar to
>> `oReq.addEventListener("load", this.responseHandler.bind(this));`
>> to get you the desired this binding.
>>
>> I’m surprised this idea hasn't been mentioned yet although things have
>> been moving slowly on that proposal and it seems to need some community
>> support to move along.
>>
>> Regards,
>> Rob
>>
>>
>> References:
>> 1: Bind Syntax Proposal (https://github.com/tc39/proposal-bind-operator)
>> 2: Babel Plugin (
>> https://babeljs.io/docs/en/next/babel-plugin-proposal-function-bind)
>>
>> ___
> 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: Loose idea on "try import"

[Ben Wiley]

Has anyone seen anything like this done in another language (with static
imports)? If so we could learn something maybe. I know you can
conditionally import in Python but that's basically the same thing as
.catch()ing dynamic import()s in JavaScript (except done synchronously).

Ben

Le ven. 1 mars 2019 15 h 26, Herby Vojčík  a écrit :

> On 1. 3. 2019 18:35, Michał Wadas wrote:
> > I don't think so, because:
> >
> >   * Using promises to import module is not always desirable
> >   * This mechanism doesn't impact ability to statically analyze modules
> > if ifs are excluded - it can only increase resolution time.
>
> Yeah, if 'if's are excluded. That version with those ifs was what was
> concerning. That actually needs runtime to do the work. I suppose until
> it doesn't need the runtime, it's all ok.
>
> >
> > On Fri, Mar 1, 2019 at 1:56 PM Herby Vojčík  > > wrote:
> >
> > On 1. 3. 2019 12:04, Michał Wadas wrote:
> >  > Syntax:
> >  >
> >  > try import fs from 'fs'
> >  > else import fs from 'fs-polyfill'
> >  > else import fs from 'another-fs-polyfill'
> >  > else do nothing; // Not sure about syntax
> >  >
> >  >
> >  > try import {watchDirectory} from 'fs'
> >  > else import {watchDirectory} from 'fs-polyfill'
> >  > else if(process.os === 'ExoticSystem') import
> > {watchDirectory} from
> >  > 'another-fs-polyfill'
> >  > else throw Error('Your OS doesn\'t support watching
> > directories');
> >
> > I am not an expert, but afaict ES module system was created to be
> > statically analysable and this bring uncertainity.
> >
> > For that probably dynamic import() is there; and your usage should
> > await
> > for a promise that tries to load one then the other etc.
> >
> > Herby
> >
> >  > Usages:
> >  >
> >  >   * Optional dependencies
> >  >   * Polyfills
> >  >
> >  > Problems:
> >  >
> >  >   * This can prevent loading modules before execution if presence
> of
> >  > modules can't be proved statically
> >  >   * else-if requires execution before loading module - can be
> dropped
> >  >
> >  >
> >  > I don't have enough time and knowledge about modules to write
> actual
> >  > proposal.
> >
>
> ___
> 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: arrow function syntax simplified

[Ben Wiley]

Purely from the standpoint of convincing people not to use fat arrows only
because they look more cute or whatever, this would be a great addition to
the language. The decision would then become which arrow is best for the
use case, no longer some trivial aesthetic argument.

Le jeu. 25 oct. 2018 10 h 09, manuelbarzi  a écrit :

> ok.
>
> as little example, what if - for any case - you would explicitly require a
> function not to be auto-binded anymore, then in the current situation you
> would need to switch code from fat-arrow `() => ...` to bureaucratic
> `function() { ... }`. with thin-arrow you would just need to change symbol
> `=` by `-`, ending in just `() -> ...`. i guess this simplicity may sound
> trivial, but it would be aligned with and ease while coding, making es+
> still thinking beyond, upon this situations and similar others (apart from
> the visible shortness and simplicity when writing `() -> ...` instead of
> `function() { ... }`).
>
> let's bring a little example on expressing an operation to be applied on
> an object by itself:
>
> ```
> const o = {
> do(expression) {
> expression.call(this)
> }
> }
>
> // cant apply or call on fat-arrow (as already binded to outer context)
> //o.do(() => this.name = 'object') // won't work
>
> // would then need to switch it to wordy `function` expression
> o.do(function() { this.name = 'object' })
>
> // but following PROPOSAL1, would just be (shorter and simpler):
> // o.do(() -> this.name = 'object')
>
> console.log(o.name)
> ```
> needless to say, less characters, more compressed code.
>
> On Thu, Oct 25, 2018 at 1:10 PM Isiah Meadows 
> wrote:
>
>> Couple nita about your argunents:
>>
>> 1. Most commonly used implementations don't close over more than what
>> they have to. If `this` isn't used, it's not closed over. The addition of
>> one more variable to check has so little overhead you won't gain anything.
>>
>> 2. Deprecating anything in JS is hard in general. The little-used
>> `arguments.caller` itself was a challenge.
>>
>> Not TC39, but I strongly doubt this would have any traction for these +
>> your additional justifications against.
>>
>> On Thu, Oct 25, 2018 at 06:59 manuelbarzi  wrote:
>>
>>> taking this old discussion back a bit (
>>> https://esdiscuss.org/topic/arrow-function-syntax-simplified), why
>>> shouldn't be a good idea to deprecate the use of "function" in pro of
>>> thin-arrow "->", being applicable in same cases (including named function)?
>>>
>>> just a bit of code with more about proposals:
>>>
>>> const GLOBAL_FACTOR = 2
>>>
>>> const result = [1, 2, 3].map(function(value) { return GLOBAL_FACTOR *
>>> value })
>>>
>>> // PROPOSAL 1 - normal anonymous function (same as fat-arrow, but
>>> dynamic binding, nothing much new here as from previous proposals):
>>> // const result = [1, 2, 3].map(value -> GLOBAL_FACTOR * value)
>>>
>>>
>>> function applyFactor(value) {
>>> return GLOBAL_FACTOR * value
>>> }
>>>
>>> // PROPOSAL 2 - named function declaration (without 'function' keyword):
>>> // applyFactor(value) -> GLOBAL_FACTOR * value
>>>
>>> // referenced function (following PROPOSAL 1):
>>> // const applyFactor = value -> GLOBAL_FACTOR * value
>>>
>>> const sameResult = [1, 2, 3].map(applyFactor)
>>>
>>> justification i read against this proposal is mainly that thin-arrow may
>>> bring "more confusion" and may "provide poor or no benefit" co-existing
>>> with fat-arrow. but having both may bring devs the chance to understand the
>>> differences in the learning process as any other feature. the only "big
>>> deal" would be to be aware of fix vs dynamic binding, which is something a
>>> dev must understand sooner or later, independently of syntax (it can be
>>> just explained with traditional function() {} and .bind() method).
>>>
>>> on the other hand it would bring the chance to avoid over-using
>>> fat-arrow when binding it's not really necessary (which may "save" internal
>>> binding processing too).
>>>
>>> finally, a simpler and shorter syntax avoiding the requirement of the
>>> keyword 'function'.
>>>
>>>
>>> ___
>>> 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: [nodejs] Re: javascript vision thing

[Ben Wiley]

I find the general tone of the preceding thread condescending toward
developers who have dealt with real problems recent ES additions have
addressed. Though I don't think I totally follow your argument that
continuing to increase API surface area decreases the surface area for
bugs. Perhaps for the developer, but certainly not for the core platform
which browsers have to implement. Also as there's a trend toward demand for
more and more language-inherent ways to accomplish the same thing, I think
we're beginning to overload newcomers to the language with grammar to learn.

Ben

Le dim. 23 sept. 2018 00 h 51, Henrique Barcelos 
a écrit :

> > 1. es6 generators and modules are the top 2 notorious things that come
> to mind as being difficult to debug/integrate in product-development.
>
> How exactly are generators and modules difficult to integrate or debug?
> Difficult compared to what?
>
> How are ES modules more complicated for the developer than CommonJS or UMD?
>
> How come generators be more complex than handling a sequence of
> asynchronous code using a user-land event-based API?
>
> How difficult would it be for Javascript engines to optimize user-land
> code?
>
> To me, it's far better to have something in the language's standard lib
> that a user-land implementation, specially for beginners.
>
> > 2. classes (and typescript, though not directly es6-related), tend to
> create lots of unnecessary structure that becomes a PITA when you need to
> rewrite everything, which occurs often in product-development. there are
> lots of newly minted js-devs entering industry, who lack experience in
> understanding the risks of javascript over-engineering (and that nothing
> you write is permanent). they write lots of semi-permanent, es6
> infrastructure-code during the initial design-phase, which is a general
> no-no for many veterans, who understand most of that stuff is going to get
> tossed out the window and rewritten during integration-phase (and again
> everytime a ux feature-request comes in that breaks the existing
> integration-workflow).
>
> What exactly is this related to classes? While I myself am not a fan of
> the whole classical syntactic sugar on top of prototypal chains, it's not
> the language's fault that its features are frequently abused and misused.
>
> What you're saying about over-engineering is not intrinsic to the
> Javascript community, it's a software engineering problem.
>
> Maybe it's because we work in a new field, with roughly 50 years (although
> programming itself has changed a lot since the 60's). Maybe it's because
> we're forming bad developers. Maybe it's because software development is a
> really complex subject.
>
> One thing we can know for sure is that the tools are not the problem. We
> are. You can use a knife to cook a delicious meal, by you can also use it
> to kill someone.
>
> > 3. let and const declarations. most code you debug/write in javascript
> is ux-related integration-code dealing with async-io, which relies heavily
> on function-scoped closures to pass variables across process-ticks.
> block-level scoping is an unnecessary design-pattern that leads to
> confusion over the former.
>
> This is an odd complaint, because variable hoisting was one of the more
> convoluted features of Javascript, simply because it was different from any
> other language I've heard of.
>
> I don't think you could even call block-level scoping a "design pattern",
> because it is a de facto standard for modern languages.
>
> > 4. fat-arrow. it has garden-path issues, making it difficult to write
> efficient javascript-parsers that can differentiate the following [valid]
> javascript-code:
> >```js
> (aa = 1, bb = 2, cc = 3);
> // vs
> (aa = 1, bb = 2, cc = 3) => aa + bb;
> ```
> >this leads to fundamental performance-issues with
> tooling/minification/test-coverage-instrumenters. jslint for
> efficiency-reasons, simply cheats and assumes both of the above are
> fat-arrows, and raises fat-arrow warnings for both (and halts further
> parsing) [1].
>
> I have never written or seen code like `(aa = 1, bb = 2, cc = 3)`. If you
> code like that, you're the problem, not JavaScript. Even though it's a
> valid construct, for compatibility sake, it doesn't mean that modern tools
> should support or endorse this.
>
> "Oh, but performance...". Yeah, you can also write a perfectly valid code
> that hurts performance as well. You can even create an infinite loop with
> valid constructs. It doesn't mean you should.
>
> ---
>
> Summarizing what I'm trying to say: your criticism has nothing to do with
> the language or its evolution pace. They are universal problems around
> software engineering and will continue to be even if we slowed down.
>
> I've been writing Javascript code since ES3 and my life got significantly
> better with ES6+.
>
> The existence of TC39 guarantees that a feature will only make it into the
> language after a very thorough public scrutiny process.
>
> I don't believe we 

Re: Proposal: defer keyword

[Ben Wiley]

If you don't need to do anything in the catch block, you can make it a
no-op and put your cleanup statement afterward.

However framing this in terms of a synchronous use case seems odd given
that synchronous database operations (your example) are extremely rare and
in JavaScript. It seems to me like promises would fit this case pretty
well, but I may have missed something.

Ben

Le jeu. 20 sept. 2018 05 h 32, Ayush Gupta  a écrit :

> It can be covered, but then I'll have to duplicate the
> `connection.release()` call in both the try and catch blocks, (and
> remember, there can be multiple resources to be cleaned up).
>
> Plus, in case that I have a function with multiple if-else branches with
> returns from multiple branches, I will have to duplicate that in all the
> branches.
>
> Another benefit of this is that this will help us logically group
> allocation and deallocation of resources together, for better readability
> and debuggability.
>
> On Thu, Sep 20, 2018 at 2:57 PM Ben Wiley 
> wrote:
>
>> Hey Ayush,
>>
>> That's an interesting language feature I hadn't heard of before.
>>
>> Any reason your use case couldn't be covered by a try/catch in the
>> synchronous case, and a promise.finally() in the async case?
>>
>> Ben
>>
>> Le jeu. 20 sept. 2018 05 h 21, Ayush Gupta  a
>> écrit :
>>
>>> Hi,
>>>
>>> I would like to propose a `defer` keyword(or something else  as the
>>> keyword name) which would allow   us to "defer" a function which will be
>>> executed once the current function either returns or throws.
>>>
>>> The idea for this is taken from the Go programming language.
>>>
>>> It would allow us to perform cleanup activities in a function which has
>>> multiple branches in a single place.
>>>
>>> For example, a sample server side code can look  like:
>>>
>>> ```  js
>>> function doSomeDbWork() {
>>> const connection = databasepool.getConnection();
>>> defer function () { connection.release(); } // function would be
>>> called no matter when/if the function returns or throws
>>> //   do your work
>>> }
>>> ```
>>>
>>> Regards
>>> Ayush Gupta
>>>
>>>
>>> ___
>>> 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: Proposal: defer keyword

[Ben Wiley]

Hey Ayush,

That's an interesting language feature I hadn't heard of before.

Any reason your use case couldn't be covered by a try/catch in the
synchronous case, and a promise.finally() in the async case?

Ben

Le jeu. 20 sept. 2018 05 h 21, Ayush Gupta  a écrit :

> Hi,
>
> I would like to propose a `defer` keyword(or something else  as the
> keyword name) which would allow   us to "defer" a function which will be
> executed once the current function either returns or throws.
>
> The idea for this is taken from the Go programming language.
>
> It would allow us to perform cleanup activities in a function which has
> multiple branches in a single place.
>
> For example, a sample server side code can look  like:
>
> ```  js
> function doSomeDbWork() {
> const connection = databasepool.getConnection();
> defer function () { connection.release(); } // function would be
> called no matter when/if the function returns or throws
> //   do your work
> }
> ```
>
> Regards
> Ayush Gupta
>
>
> ___
> 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: constructor, super, and data members issue

[Ben Wiley]

How can they be prototypically inherited if they don't live on the
prototype? I feel like I'm missing something.

Le sam. 25 août 2018 19 h 53, Isiah Meadows  a
écrit :

> Class fields are prototypically inherited just like via `Object create`.
> This is more useful than you might think, and it's the main reason anyone
> actually cares about static fields beyond namespacing.
> On Sat, Aug 25, 2018 at 14:36 Ben Wiley  wrote:
>
>> All this just reminds me of *my opinion* that class fields is a borrowed
>> concept from statically typed languages that is misplaced in a dynamically
>> typed languages like JavaScript.
>>
>> In C++ I use class fields to declare what properties will be allocated
>> and instantiated when a new class member is constructed.
>>
>> In the ES proposal for class fields we mimic this type of behavior by
>> instantiating properties on the object when it's constructed, but there's
>> no runtime guarantee that this set of properties will remain the same.
>>
>> There's no reason not to put this in the constructor, and although
>> putting class fields on the prototype is debatably not the best idea, it
>> would be the only scenario where we get some kind of new helpful behavior
>> out of it.
>>
>> Ben
>>
>> Le sam. 25 août 2018 14 h 25, Augusto Moura 
>> a écrit :
>>
>>> 24-08-2018 19:29, Aaron Gray :
>>>
>>> >
>>> > Yeah it does look like its badly "broken by design".
>>> >
>>>
>>> Why this behaviour is broken? Every OOP language that I worked with
>>> behaves de same way, and there's not many developers complaining about
>>> it. If you want to use a property that might be overrided in a
>>> subclasss you need to use a method and make the source of the data
>>> more versatile (in Java and others similiar languages we have to
>>> implement it using getter methods). Luckily Javascript doesn't need
>>> getter and setters methods to make a property overridable because of
>>> getter and setters descriptors, so we can workaround the first example
>>> easily:
>>>
>>> ``` js
>>> class Bar {
>>>   bar = 'in bar';
>>>
>>>   constructor() {
>>> console.log(this.bar)
>>>   }
>>> }
>>>
>>> class Foo extends Bar {
>>>   _initiedSuper = false;
>>>   _bar = 'in foo';
>>>
>>>   constructor() {
>>> super();
>>> this._initiedSuper = true;
>>>   }
>>>
>>>   get bar() {
>>> return this._bar;
>>>   }
>>>
>>>   set bar(val) {
>>> if (this._initiedSuper) {
>>>   this._bar = val;
>>> }
>>>   }
>>> }
>>>
>>> new Foo(); // will log 'in foo'
>>> ```
>>>
>>> *I have to say the relaying that the super constructor will use the
>>> bar property and workarounding it **is a bad practice** and should be
>>> avoided at any costs. The contract with the super class constructor
>>> should rely only on the super call, these situations just reveal bad
>>> design choices in the super class. Logan Smyth example is the correct
>>> answer to this problem*
>>>
>>>
>>> 25-08-2018 01:28, Jordan Harband :
>>>
>>> >
>>> > Personally I think a design where the superclass relies on any part of
>>> the
>>> > subclass is "broken by design"; but certainly there's ways you can
>>> achieve
>>> > that.
>>> >
>>>
>>> Of course is not broken. The super class has a contract with a
>>> parametrized option, it can be used in subclasses or just in a
>>> constructor call `new Base({ idAttribute: 'foo' })`, if it has a
>>> default value for that is not a sub class concern. When refactoring
>>> code adding defaults and "lifting" parameters are very common ~not
>>> only on OOP~ and relying that the super class is using some property
>>> in the constructor is the real "broken by design".
>>> ___
>>> 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: constructor, super, and data members issue

[Ben Wiley]

All this just reminds me of *my opinion* that class fields is a borrowed
concept from statically typed languages that is misplaced in a dynamically
typed languages like JavaScript.

In C++ I use class fields to declare what properties will be allocated and
instantiated when a new class member is constructed.

In the ES proposal for class fields we mimic this type of behavior by
instantiating properties on the object when it's constructed, but there's
no runtime guarantee that this set of properties will remain the same.

There's no reason not to put this in the constructor, and although putting
class fields on the prototype is debatably not the best idea, it would be
the only scenario where we get some kind of new helpful behavior out of it.

Ben

Le sam. 25 août 2018 14 h 25, Augusto Moura  a
écrit :

> 24-08-2018 19:29, Aaron Gray :
>
> >
> > Yeah it does look like its badly "broken by design".
> >
>
> Why this behaviour is broken? Every OOP language that I worked with
> behaves de same way, and there's not many developers complaining about
> it. If you want to use a property that might be overrided in a
> subclasss you need to use a method and make the source of the data
> more versatile (in Java and others similiar languages we have to
> implement it using getter methods). Luckily Javascript doesn't need
> getter and setters methods to make a property overridable because of
> getter and setters descriptors, so we can workaround the first example
> easily:
>
> ``` js
> class Bar {
>   bar = 'in bar';
>
>   constructor() {
> console.log(this.bar)
>   }
> }
>
> class Foo extends Bar {
>   _initiedSuper = false;
>   _bar = 'in foo';
>
>   constructor() {
> super();
> this._initiedSuper = true;
>   }
>
>   get bar() {
> return this._bar;
>   }
>
>   set bar(val) {
> if (this._initiedSuper) {
>   this._bar = val;
> }
>   }
> }
>
> new Foo(); // will log 'in foo'
> ```
>
> *I have to say the relaying that the super constructor will use the
> bar property and workarounding it **is a bad practice** and should be
> avoided at any costs. The contract with the super class constructor
> should rely only on the super call, these situations just reveal bad
> design choices in the super class. Logan Smyth example is the correct
> answer to this problem*
>
>
> 25-08-2018 01:28, Jordan Harband :
>
> >
> > Personally I think a design where the superclass relies on any part of
> the
> > subclass is "broken by design"; but certainly there's ways you can
> achieve
> > that.
> >
>
> Of course is not broken. The super class has a contract with a
> parametrized option, it can be used in subclasses or just in a
> constructor call `new Base({ idAttribute: 'foo' })`, if it has a
> default value for that is not a sub class concern. When refactoring
> code adding defaults and "lifting" parameters are very common ~not
> only on OOP~ and relying that the super class is using some property
> in the constructor is the real "broken by design".
> ___
> 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: javascript vision thing

[Ben Wiley]

Please refrain from jokes about domestic violence. It distracted from the
rest of your email, which I decided not to read.

Ben

Le mar. 24 juill. 2018 11 h 09, Carsten Bormann  a écrit :

> On Jul 24, 2018, at 16:31, Anders Rundgren 
> wrote:
> >
> > JSON isn’t really a topic for tc39 only but since the IETF consider JSON
> "done", an open question is where possible future developments should take
> place,
>
> What is the best place where I should beat my wife?
> No, that is not the question.
>
> > including dealing with new data types like BigInt.
>
> That, indeed, is a question for JavaScript.  It has nothing to do with
> “developing” JSON; JSON can already represent BigInt just fine.
>
> > Personally I think the JSON WG should be rebooted but apparently I’m
> rather alone with that idea.
>
> Indeed.
>
> Frankly, JSON, together with the JavaScript-induced limitations in its
> ecosystem as documented in RFC 7493, is not a very brilliant data
> interchange format.  It is popular because it is extremely simple (at least
> on the surface), it is already familiar to users of most dynamic
> programming languages, and it hasn’t changed since 2002.  “Changing” JSON
> simply means no longer having JSON.
>
> (And there are quite a few much better data interchange formats; maybe
> JavaScript can start to support some of them out of the box.)
>
> > Obvious extensions include comments and dropping the "" requirement on
> keys that are JS compliant.
>
> *Shudder*.   These are *not* needed for data interchange.  For
> configuration files and other data input by humans, DO NOT USE JSON.  If
> you need YAML(*) (which also has been fully stable for more than a decade,
> by the way), you know where to find it.  YAML also *is* the extended JSON
> that so many people are wishing for.
>
> Grüße, Carsten
>
> (*) and of course YAML supports graphs, binary (byte string) data,
> human-friendly input, etc.  It is approximately what any other effort to
> “humanize” JSON and fill in its shortcomings will arrive at eventually,
> just with some microdecisions you and I may not like but that are not
> relevant in the big picture.
>
> ___
> 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: proposal: Object Members

[Ben Wiley]

I see, so it's not that you can't do things without class as much as you
can impose limitations by using class. Thanks for clarifying

Le lun. 23 juill. 2018 18 h 49, Jordan Harband  a écrit :

> When extending builtins, `super()` is the only way you can get the
> appropriate internal slots applied to the instance. (Private fields work
> the same way by providing a matching guarantee - that the only way someone
> can subclass you successfully is using `class extends` and `super`)
>
> On Mon, Jul 23, 2018 at 3:43 PM, Ben Wiley 
> wrote:
>
>> What exactly can be accomplished with super that can't be accomplished
>> otherwise? I know the transpiled code is very verbose and unintuitive to
>> read if you avoid explicitly naming the base class, but I wasn't aware of
>> new capabilities that were previously impossible.
>>
>> Ben
>>
>>
>> Le lun. 23 juill. 2018 18 h 06, Ranando King  a
>> écrit :
>>
>>> Granted about `super()`. That's the one thing I can't easily reproduce.
>>> However, barring those internal slots, I can reproduce the functionality of
>>> `super` and the checks performed as a result of the internal slots, all in
>>> ES6. As for built-ins, I can easily and properly extend builtins without
>>> `class` since ES6 officially has `Object.setPrototypeOf()`. If you don't
>>> think it's possible, you should take a close look at what I'm doing in the
>>> repl.it link from my first post.
>>>
>>> As for whether or not the sugary nature of `class` is a good thing, it
>>> really is a matter of opinion. I just happen to be of the persuasion that
>>> since there's literally no construct that `class` can produce that I cannot
>>> reproduce by other means, then that means the `class` keyword (even in
>>> light of `super`) is little more than syntactic sugar. As such, we
>>> shouldn't be so hasty to turn an Object Oriented Prototype Based language
>>> into an Object Oriented Class Based language. The only way to do that
>>> reasonably is to ensure that whatever you can construct with `class` can
>>> always be equivalently constructed without it.
>>>
>>> Here's a more logical argument instead. Even if there are subtle
>>> differences between `class` constructors and object factory functions,
>>> providing an isolated path specific to `class` is likely to lead to
>>> situations very similar to what happens when an open source package gets
>>> forked. Eventually, the difference between the two paths may become so
>>> great that one is eventually abandoned (by developers) in favor of the
>>> other. This is only a valid argument because the power of ES is in it's
>>> simplicity. It's like building a house with wood, nails, sheetrock, etc...
>>> (JS) vs. building a house with pre-fabricated parts (class-based languages).
>>>
>>> Don't get me wrong. The `class` keyword is a great thing. It simplifies
>>> the production of creating object factories with prototypes. As I
>>> understand it, that was the purpose. Let's not make the mistake of allowing
>>> something to be done with `class` that cannot be reasonably reproduced
>>> without it. The moment we do that, we're diverging from the intended
>>> purpose of `class`.
>>>
>>>
>>>
>>> On Mon, Jul 23, 2018 at 4:17 PM Jordan Harband  wrote:
>>>
>>>> Extend builtins, in particular - ie, `super()` allows your subclass to
>>>> obtain internal slots it can't otherwise get.
>>>>
>>>> Even if `class` were just sugar, I don't think I see the argument that
>>>> that's a *good* thing to preserve.
>>>>
>>>> On Mon, Jul 23, 2018 at 2:05 PM, Ranando King 
>>>> wrote:
>>>>
>>>>>
>>>>>
>>>>> -- Forwarded message -
>>>>> From: Ranando King 
>>>>> Date: Mon, Jul 23, 2018 at 4:04 PM
>>>>> Subject: Re: proposal: Object Members
>>>>> To: 
>>>>>
>>>>>
>>>>> You've made that argument before. Exactly what is it in ES6 that you
>>>>> **can** do with `class` that you cannot do without class? I'd like some
>>>>> clarification on this.
>>>>>
>>>>> On Mon, Jul 23, 2018 at 3:30 PM Jordan Harband 
>>>>> wrote:
>>>>>
>>>>>> `class` is already not just syntactic sugar, so that notion isn't
>>>>>> correct, and shouldn't be maintained.
>>>>>>
>>>>>&

Re: proposal: Object Members

[Ben Wiley]

What exactly can be accomplished with super that can't be accomplished
otherwise? I know the transpiled code is very verbose and unintuitive to
read if you avoid explicitly naming the base class, but I wasn't aware of
new capabilities that were previously impossible.

Ben


Le lun. 23 juill. 2018 18 h 06, Ranando King  a écrit :

> Granted about `super()`. That's the one thing I can't easily reproduce.
> However, barring those internal slots, I can reproduce the functionality of
> `super` and the checks performed as a result of the internal slots, all in
> ES6. As for built-ins, I can easily and properly extend builtins without
> `class` since ES6 officially has `Object.setPrototypeOf()`. If you don't
> think it's possible, you should take a close look at what I'm doing in the
> repl.it link from my first post.
>
> As for whether or not the sugary nature of `class` is a good thing, it
> really is a matter of opinion. I just happen to be of the persuasion that
> since there's literally no construct that `class` can produce that I cannot
> reproduce by other means, then that means the `class` keyword (even in
> light of `super`) is little more than syntactic sugar. As such, we
> shouldn't be so hasty to turn an Object Oriented Prototype Based language
> into an Object Oriented Class Based language. The only way to do that
> reasonably is to ensure that whatever you can construct with `class` can
> always be equivalently constructed without it.
>
> Here's a more logical argument instead. Even if there are subtle
> differences between `class` constructors and object factory functions,
> providing an isolated path specific to `class` is likely to lead to
> situations very similar to what happens when an open source package gets
> forked. Eventually, the difference between the two paths may become so
> great that one is eventually abandoned (by developers) in favor of the
> other. This is only a valid argument because the power of ES is in it's
> simplicity. It's like building a house with wood, nails, sheetrock, etc...
> (JS) vs. building a house with pre-fabricated parts (class-based languages).
>
> Don't get me wrong. The `class` keyword is a great thing. It simplifies
> the production of creating object factories with prototypes. As I
> understand it, that was the purpose. Let's not make the mistake of allowing
> something to be done with `class` that cannot be reasonably reproduced
> without it. The moment we do that, we're diverging from the intended
> purpose of `class`.
>
>
>
> On Mon, Jul 23, 2018 at 4:17 PM Jordan Harband  wrote:
>
>> Extend builtins, in particular - ie, `super()` allows your subclass to
>> obtain internal slots it can't otherwise get.
>>
>> Even if `class` were just sugar, I don't think I see the argument that
>> that's a *good* thing to preserve.
>>
>> On Mon, Jul 23, 2018 at 2:05 PM, Ranando King  wrote:
>>
>>>
>>>
>>> -- Forwarded message -
>>> From: Ranando King 
>>> Date: Mon, Jul 23, 2018 at 4:04 PM
>>> Subject: Re: proposal: Object Members
>>> To: 
>>>
>>>
>>> You've made that argument before. Exactly what is it in ES6 that you
>>> **can** do with `class` that you cannot do without class? I'd like some
>>> clarification on this.
>>>
>>> On Mon, Jul 23, 2018 at 3:30 PM Jordan Harband  wrote:
>>>
 `class` is already not just syntactic sugar, so that notion isn't
 correct, and shouldn't be maintained.

 On Mon, Jul 23, 2018 at 12:38 PM, Ranando King 
 wrote:

> I've written up a new draft proposal based on my own work with ES5 &
> ES6 compatible classes with fields. That can be found [here](
> https://github.com/rdking/proposal-object-members). I'm already aware
> of the class-members proposal, but I think it breaks far to many things 
> and
> doesn't do anything to maintain the notion that "`class` is just syntactic
> sugar".
>
> This proposal is specifically based on the code [here](
> https://github.com/rdking/Class.js/tree/master/es6c). I've also got a
> [repl.it](https://repl.it/@arkain/Classjs-Compact-Syntax-ES6) that
> shows the same code running.
>
> The idea behind the proposal is that instead of injecting a lot of new
> logic into how `class` works, let's allow `class` to remain syntactic
> sugar, and put that extra ability into object declarations instead. Then
> simply allow `class` to do the same with it's own prototypes.
>
> ___
> 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: [proposal] Persistent variables in functions/methods

[Ben Wiley]

@peter: I think you made some valid point in there but you could have been
more concise and nicer :)
https://www.destroyallsoftware.com/blog/2018/a-case-study-in-not-being-a-jerk-in-open-source

@Neek: worth noting that your compiled example is not semantically
identical to the proposed behavior. In the closure example the persistent
variables are initialized at the time the inner function is defined, not at
the time it is first called. If it's initialized at the time of function
definition then there's no persist access to local variables inside the
function itself (although different than C++, not a bad thing imo!).

Ben


Le mar. 17 juill. 2018 01 h 51, Neek Sandhu  a
écrit :

> > re@Ben
>
>
>
>1. `persist` because didn’t want to bring in the dark connotation
>associated with `static` variables in C++. Although `persist` is just an
>example to prove a point, could be anything really (even `static` )
>2. As for my knowledge and understanding, I’d imagine these to behave
>just like closures w/ IIFE
>
>
>
> ```javascript
>
> function foo(n) {
>
> // initialized on first call to foo, persists for subsequent calls
>
> persist let counter =  0;
>
>
>
> // this way JS engine won't have to recompile the pattern everytime
>
> persist const httpRE = /^https?/;
>
>
>
> counter++;
>
> return n * a;
>
> }
>
> ```
>
>
>
> is 1:1 as
>
>
>
> ```javascript
>
> let foo = (() => {
>
> let counter = 0;
>
> const httpRE = /^https?/;
>
> return (n) => {
>
> counter++;
>
> return  n * a;
>
> }
>
> })()
>
> ```
>
>
>
> Revisions to this are welcome of course
>
>
>
>
>
>1. Ref #2
>2. Umm…. Lets just say the fact we need to preserve state (like
>`counter` or `lastValue`) is good enough selling point
>3. This proposal aims for and enforces, once again, the motto that stuff
>should “live” where it “belongs” and not “leak” out unnecessarily
>4. Ref #5 and also see my reply to jhpratt that explains how this
>fails when class methods are in question (see `DBService` class example)
>
>
> ___
> 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: [proposal] Persistent variables in functions/methods

[Ben Wiley]

I generally think JavaScript is a much better looking language than C++ but
this is one of my favorite C++ features, so it's interesting to see it
considered for JavaScript.

A few questions:

1. I'm wondering if there's a strong argument for using the word `persist`
rather than `static` as C++ does. Certainly this isn't the same thing as a
static class member but they're not dissimilar concepts, and use areas are
different enough to avoid language ambiguity.
2. Does the static initialization have access to non-static variables,
function parameters or `this` members? Might be less error prone if not,
but maybe they are compelling use cases for that.
3. Many folks in C++ land seem to think static variables are overused and
abused. Do we think the benefits outweigh the pitfalls here?
4. Are we certain JS engines can't/don't perform the optimization that we
would get from static const variables?
5. Doesn't module level scope in es2015+ give us basically the same benefit
we would get for static const vars in functions? Sure it's not declared in
the same place, but it's still well encapsulated and not available off the
object or class itself.
6. Is there a great reason for static let rather than defining the "static"
variable in an outer closure per your code example?

My own tentative answers are:
1. static is better than persist unless we really think people won't
understand how it's different than static class members
2. disallow unless there's a clearly good use case
3. not sure
4. no idea
5. I think I always use module scope in JS where I would use static const
in C++. Seems pretty good even if it reads a bit differently. Arguably
better because variable lifetime is apparent based on indentation.
6. I think there's an argument here for conciseness.. other than that I'm
not sure what the reason would be (unless you have a good use case for #2).

Ben

Le mar. 17 juill. 2018 00 h 56, Neek Sandhu  a
écrit :

> It'd be really useful to have variables inside methods/functions that are
> initialized once, reused for subsequent calls and live as long as
> containing scope i.e the function itself.
>
> > not to be confused with `static` properties
>
> ## Use Cases
>
> Almost every app has a function or method that needs to "preserve" some
> state across multiple calls, a counter for example. Current ways out of
> this situation are either closures created with IIFE's or making those
> variables top-level. Both of which are ugly. I think the same could be done
> much more neatly with persistent variables.
>
> ## Example
>
> ```javascript
> function foo(n) {
> // initialized on first call to foo, persists for subsequent calls
> persist let counter =  0;
>
> // this way JS engine won't have to recompile the pattern everytime
> persist const httpRE = /^https?/;
>
> counter++;
> return n * a;
> }
> ```
>
> is 1:1 as
>
> ```javascript
> let foo = (() => {
> let counter = 0;
> const httpRE = /^https?/;
> return (n) => {
> counter++;
> return  n * a;
> }
> })()
> ```
>
> ___
> 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: Array.prototype.replace

[Ben Wiley]

eline operator starts to feel like you're using Lisp,
>> > not
>> > JS, because of the sheer number of operators. (It's an array over
>> > *time*,
>> > not *space*, so you have things like debouncing, throttling, etc. that
>> you
>> > have to address.) Iterables are in a similar situation because they're
>> > lazy, it's protocol-based rather than prototype-based, and JS lacks
>> > anything like monads.
>> >
>> > -
>> >
>> > Isiah Meadows
>> > m...@isiahmeadows.com
>> > www.isiahmeadows.com
>> >
>> > On Tue, Jul 10, 2018 at 11:18 AM, Ben Wiley 
>> > wrote:
>> >
>> >> It’s not clear to me that pursuit of new Array methods should be
>> >> abandoned
>> >> purely on speculation that the pipe operator will pass Stage 1.
>> >>
>> >>
>> >>
>> >> That said, the realization that Object.assign provides this
>> functionality
>> >> is enough for me to quit pursuing (my version of)
>> >> Array.prototype.replace.
>> >>
>> >>
>> >>
>> >> I’d prefer that further discussion concern the earlier-discussed
>> >> extension
>> >> to the Array rest spread syntax. :)
>> >>
>> >>
>> >>
>> >> Ben
>> >>
>> >>
>> >>
>> >> *From: *Andrea Giammarchi 
>> >> *Date: *Tuesday, July 10, 2018 at 10:50 AM
>> >> *To: *"T.J. Crowder" 
>> >> *Cc: *"therealbenwi...@gmail.com" , "
>> >> es-discuss@mozilla.org" 
>> >> *Subject: *Re: Array.prototype.replace
>> >>
>> >>
>> >>
>> >> just a few days ago another full stack JS dev mentioned Array replace
>> and
>> >> it has nothing to do with what was proposed in here:
>> >>
>> >> https://medium.com/@gajus/the-case-for-array-replace-cd9330707243
>> >>
>> >>
>> >>
>> >> My TL;DR response was that once the pipe operator is in, everyone can
>> >> bring in its own meaning for `array |> replace` and call it a day.
>> >>
>> >>
>> >>
>> >> Keep polluting the already most polluted prototype of them all doesn't
>> >> look like a good strategy to improve the language.
>> >>
>> >>
>> >>
>> >> Just my 2 cents.
>> >>
>> >>
>> >>
>> >>
>> >>
>> >>
>> >>
>> >> On Tue, Jul 10, 2018 at 3:37 PM T.J. Crowder <
>> >> tj.crow...@farsightsoftware.com> wrote:
>> >>
>> >> On Tue, Jul 10, 2018 at 2:18 PM, Ben Wiley 
>> >> wrote:
>> >> > Hm, despite the fewer number of points in the cons category I'm
>> >> persuaded by
>> >> > the argument that we don't want people getting arrays and objects
>> >> confused.
>> >> > Might be best to limit that until there is a compelling use case
>> >> > which
>> >> there
>> >> > might not be.
>> >>
>> >> Heh, whereas despite having written that first bullet in the footgun
>> >> column somewhat forcefully (looking back), I go the other way. :-)
>> >>
>> >>
>> >>
>> >> -- T.J. Crowder
>> >>
>> >> ___
>> >> 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: Small Proposal "!in"

[Ben Wiley]

I find the juxtaposition of a symbol operator against an English operator a
bit odd, but I think most English speakers pronounce "!" as "not" so you
might not have so much to worry about..

Le mer. 11 juill. 2018 11 h 24, Alex Vincent  a écrit :

> -- Forwarded message --
>> From: Andrea Giammarchi 
>> To: Jordan Harband 
>> Cc: "es-discuss@mozilla.org" 
>> Bcc:
>> Date: Wed, 11 Jul 2018 16:23:03 +0200
>> Subject: Re: Small Proposal "!in"
>> and, as previously mentioned, `!obj.x` might have side effects through
>> the accessor, as example in every lazily defined property that would be
>> early defined (or anything else behind a getter that could do more than
>> just telling the property is there and it's not truthy).
>>
>
> Peanut gallery observation: I personally think !in is a Really Bad Idea,
> or at least I'm not convinced that it's particularly useful.  If it is
> useful, then let one of the transpiling languages like CoffeeScript or
> TypeScript demonstrate it first.
>
> Also, there's the little matter of pronunciation.  I admit to a bit of
> snarkiness when I first saw this proposal, but I didn't expect it to have
> any traction.  So I'll just say it:  do we really want JavaScript to be a
> "bangin' " language?
>
> Alex
>
> --
> "The first step in confirming there is a bug in someone else's work is
> confirming there are no bugs in your own."
> -- Alexander J. Vincent, June 30, 2001
> ___
> 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: Array.prototype.replace

[Ben Wiley]

It’s not clear to me that pursuit of new Array methods should be abandoned 
purely on speculation that the pipe operator will pass Stage 1.

That said, the realization that Object.assign provides this functionality is 
enough for me to quit pursuing (my version of) Array.prototype.replace.

I’d prefer that further discussion concern the earlier-discussed extension to 
the Array rest spread syntax. :)

Ben

From: Andrea Giammarchi 
Date: Tuesday, July 10, 2018 at 10:50 AM
To: "T.J. Crowder" 
Cc: "therealbenwi...@gmail.com" , 
"es-discuss@mozilla.org" 
Subject: Re: Array.prototype.replace

just a few days ago another full stack JS dev mentioned Array replace and it 
has nothing to do with what was proposed in here:
https://medium.com/@gajus/the-case-for-array-replace-cd9330707243

My TL;DR response was that once the pipe operator is in, everyone can bring in 
its own meaning for `array |> replace` and call it a day.

Keep polluting the already most polluted prototype of them all doesn't look 
like a good strategy to improve the language.

Just my 2 cents.



On Tue, Jul 10, 2018 at 3:37 PM T.J. Crowder 
mailto:tj.crow...@farsightsoftware.com>> wrote:
On Tue, Jul 10, 2018 at 2:18 PM, Ben Wiley 
mailto:therealbenwi...@gmail.com>> wrote:
> Hm, despite the fewer number of points in the cons category I'm persuaded by
> the argument that we don't want people getting arrays and objects confused.
> Might be best to limit that until there is a compelling use case which there
> might not be.
Heh, whereas despite having written that first bullet in the footgun column 
somewhat forcefully (looking back), I go the other way. :-)

-- T.J. Crowder
___
es-discuss mailing list
es-discuss@mozilla.org<mailto: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: Array.prototype.replace

[Ben Wiley]

Hm, despite the fewer number of points in the cons category I'm persuaded
by the argument that we don't want people getting arrays and objects
confused. Might be best to limit that until there is a compelling use case
which there might not be.

Ben

Le mar. 10 juill. 2018 09 h 16, Ben Wiley  a
écrit :

>
>
> Le mar. 10 juill. 2018 09 h 14, T.J. Crowder <
> tj.crow...@farsightsoftware.com> a écrit :
>
>> On Tue, Jul 10, 2018 at 1:22 PM, Ben Wiley 
>> wrote:
>> > Here's a spec question: must the keys specified be numbers? The
>> application
>> > is questionable but I say anything could be allowed. E.g.
>> > ...
>> > So array rest spread would provide totally parallel functionality to
>> object
>> > rest spread with the key difference that result objects are arrays
>> instead
>> > of objects.
>>
>> I'd call it a minor point. But off-the-cuff:
>>
>> There's always a hopefully-creative tension between A) not
>> unnecessarily limiting things, and B) YAGNI and/or not handing people
>> footguns.
>>
>> In the "don't unnecessarily limit" column:
>>
>> * The ship has already sailed in terms of people confusing arrays and
>> objects in JavaScript.
>> * Not limiting to array index property names should mean the same
>> parsing structures and code can be used.
>> * I don't like unnecessary runtime checks, and the check that the
>> property name is an array index would have to be at runtime, not
>> parse-time, because of computed property names.
>> * Standard array indexes are officially strings anyway (though we
>> write them as numbers and they get optimized that way most of the
>> time).
>> * `[length: 10]` has a certain seductive quality about it.
>>
>> In the YAGNI and/or footgun column:
>>
>> * People already get objects and arrays confused enough! At least
>> right now, if they write `[foo: "bar"]`, they get a syntax error
>> (though of course `{0: "bar"}` is perfectly valid). Don't hand them
>> yet another footgun.
>> * As you say, application is questionable.
>>
>> -- T.J. Crowder
>>
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Array.prototype.replace

[Ben Wiley]

Le mar. 10 juill. 2018 09 h 14, T.J. Crowder <
tj.crow...@farsightsoftware.com> a écrit :

> On Tue, Jul 10, 2018 at 1:22 PM, Ben Wiley 
> wrote:
> > Here's a spec question: must the keys specified be numbers? The
> application
> > is questionable but I say anything could be allowed. E.g.
> > ...
> > So array rest spread would provide totally parallel functionality to
> object
> > rest spread with the key difference that result objects are arrays
> instead
> > of objects.
>
> I'd call it a minor point. But off-the-cuff:
>
> There's always a hopefully-creative tension between A) not
> unnecessarily limiting things, and B) YAGNI and/or not handing people
> footguns.
>
> In the "don't unnecessarily limit" column:
>
> * The ship has already sailed in terms of people confusing arrays and
> objects in JavaScript.
> * Not limiting to array index property names should mean the same
> parsing structures and code can be used.
> * I don't like unnecessary runtime checks, and the check that the
> property name is an array index would have to be at runtime, not
> parse-time, because of computed property names.
> * Standard array indexes are officially strings anyway (though we
> write them as numbers and they get optimized that way most of the
> time).
> * `[length: 10]` has a certain seductive quality about it.
>
> In the YAGNI and/or footgun column:
>
> * People already get objects and arrays confused enough! At least
> right now, if they write `[foo: "bar"]`, they get a syntax error
> (though of course `{0: "bar"}` is perfectly valid). Don't hand them
> yet another footgun.
> * As you say, application is questionable.
>
> -- T.J. Crowder
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Array.prototype.replace

[Ben Wiley]

T.J., thanks for pointing out that Object.assign provides the same
functionality. I'd neglected to consider that the first argument needn't be
a plain object.

Interesting that folks seems to prefer the syntax variant more than I had
expected.

As for the application of providing a destructuring parallel.. well, you've
convinced me it could be useful. :)

Here's a spec question: must the keys specified be numbers? The application
is questionable but I say anything could be allowed. E.g.

```js
const arr1 = [1,2,3]
const arr2 = [...arr1, foo: 'bar' ]
```

Or

```js
const [ 1: middle, foo, ...arr3 ] = arr2
console.log(middle, foo, arr3) // 2 "bar" [1, 3]
```

So array rest spread would provide totally parallel functionality to object
rest spread with the key difference that result objects are arrays instead
of objects.

Thoughts?

Ben

Le 10 juill. 2018 02 h 48, "T.J. Crowder" 
a écrit :

Hi,

The standard library already handles doing array-copy-and-update as a
one-liner via `Object.assign` (http://jsfiddle.net/ryqtvbdk/):

```js
const original = [1, 2, 3, 4];
const updated = Object.assign([...original], {1: 4, 3: 42});
// Or: const updated = Object.assign([], original, {1: 4, 3: 42});
console.log(updated); // [1, 4, 3, 42]
```

Like Isiah, I think I'd prefer it as syntax. I'm not an engine implementer
so I have no idea how hard it would be to do this to an array initializer:

```js
const original = [1, 2, 3];
const updated = [...original, 1: 4];
console.log(updated); // [1, 4, 3]
```

...but that's what I'd like to see. Parallels the object initializer.
Currently invalid syntax, so safe to add from that perspective. And it
enhances destructuring as well (since array initializer syntax is used for
destructuring):

```js
const original = [1, 2, 3];
const [1: foo, ...rest] = original;
console.log(foo); // 2
console.log(rest); // [1, 3]
```

(Note that `rest` is an array, whereas with an object destructuring
pattern, it would be a non-array object.)

That syntax would also provide expressive creation of sparse arrays, e.g.:

```js
const array = [2: 42];
console.log(array); // [, , 42];
```

-- T.J. Crowder
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Array.prototype.replace

[Ben Wiley]

P.S. sorry for the double post but should mention the word "convenient"
came from nowhere (except autocorrect) in my last message. I wasn't calling
your example "inconvenient." :)

Le mar. 10 juill. 2018 01 h 26, Ben Wiley  a
écrit :

> Oops, meant to send to the rest of the list.
>
> Thanks for the feedback Isiah.
> 1. Fair!
> 2. Could you elaborate? I believe that's what this is, though I might be
> missing your point.
> 3. a. As I noted on GitHub I also considered that syntax originally. I'm
> torn on it because allowing out-of-order index definitions in an array
> little seems a bit wacky, but maybe it's not so bad?
> b. Hmm, this sounds interesting but I'm not sure I totally follow. Could
> you give a more convenient concrete example of the array pattern type for
> the example you're discussing?
>
> Ben
>
>
> Le mar. 10 juill. 2018 00 h 15, Isiah Meadows  a
> écrit :
>
>> I like the idea, but there's a few tweaks I think could be made:
>>
>> 1. `replace` reads like you're doing a string or subarray replace.
>> This proposal sounds more like an `update`.
>> 2. If you allow it to carry the semantics of `slice()` + `array[index]
>> = value`, engines can implement it a bit quicker.
>> 3. IMHO, this belongs as syntax, either in addition or in place of
>> this proposal's method. If nothing else, it's for consistency with
>> object spread, but it also allows you to spread iterables similarly,
>> something like `[...iter, index: value]`. We could also introduce that
>> as an array pattern type, so we don't need to use elisions so
>> frequently to skip values in array destructuring patterns (think:
>> `regexp.exec(string)` results, when you don't care about all the
>> groups). There's been times where I've had upwards of 3-4 elisions all
>> clustered together, and that gets unreadable in a hurry.
>>
>> -
>>
>> Isiah Meadows
>> m...@isiahmeadows.com
>> www.isiahmeadows.com
>>
>>
>> On Mon, Jul 9, 2018 at 11:42 PM, Ben Wiley 
>> wrote:
>> > Hi ECMAScript folks,
>> >
>> > I'm brand new to this process and I've drafted a proposal (and
>> polyfill) for
>> > a new Array.prototype.replace method. In the vein of Array concat,
>> String
>> > replace and the new Object rest spread, Array replace provides a way to
>> > shallow clone an array and replace an element in a single statement.
>> >
>> > Here's the GitHub repo, which outlines API, motivation, use cases,
>> > alternatives, and polyfill usage:
>> > https://github.com/benwiley4000/array-replace
>> >
>> > Array replace shouldn't be considered an across-the-board substitute for
>> > Array.prototype.splice (which mutates the array) and wouldn't be ideal
>> for
>> > performance critical applications handling very large arrays. It is well
>> > suited for application logic where immutability is desired - a trend
>> growing
>> > in the Javascript community.
>> >
>> > Most of the application areas of object rest spread composition syntax
>> (for
>> > building objects, not destructuring them) are also application areas for
>> > Array.prototype.replace, when your object happens to be an array.
>> >
>> > I'm looking forward to any feedback and I'd also love for a champion to
>> step
>> > in and help, if you think this is an ok idea.
>> >
>> > Thanks!
>> > Ben
>> >
>> > ___
>> > 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: Array.prototype.replace

[Ben Wiley]

Oops, meant to send to the rest of the list.

Thanks for the feedback Isiah.
1. Fair!
2. Could you elaborate? I believe that's what this is, though I might be
missing your point.
3. a. As I noted on GitHub I also considered that syntax originally. I'm
torn on it because allowing out-of-order index definitions in an array
little seems a bit wacky, but maybe it's not so bad?
b. Hmm, this sounds interesting but I'm not sure I totally follow. Could
you give a more convenient concrete example of the array pattern type for
the example you're discussing?

Ben


Le mar. 10 juill. 2018 00 h 15, Isiah Meadows  a
écrit :

> I like the idea, but there's a few tweaks I think could be made:
>
> 1. `replace` reads like you're doing a string or subarray replace.
> This proposal sounds more like an `update`.
> 2. If you allow it to carry the semantics of `slice()` + `array[index]
> = value`, engines can implement it a bit quicker.
> 3. IMHO, this belongs as syntax, either in addition or in place of
> this proposal's method. If nothing else, it's for consistency with
> object spread, but it also allows you to spread iterables similarly,
> something like `[...iter, index: value]`. We could also introduce that
> as an array pattern type, so we don't need to use elisions so
> frequently to skip values in array destructuring patterns (think:
> `regexp.exec(string)` results, when you don't care about all the
> groups). There's been times where I've had upwards of 3-4 elisions all
> clustered together, and that gets unreadable in a hurry.
>
> -
>
> Isiah Meadows
> m...@isiahmeadows.com
> www.isiahmeadows.com
>
>
> On Mon, Jul 9, 2018 at 11:42 PM, Ben Wiley 
> wrote:
> > Hi ECMAScript folks,
> >
> > I'm brand new to this process and I've drafted a proposal (and polyfill)
> for
> > a new Array.prototype.replace method. In the vein of Array concat, String
> > replace and the new Object rest spread, Array replace provides a way to
> > shallow clone an array and replace an element in a single statement.
> >
> > Here's the GitHub repo, which outlines API, motivation, use cases,
> > alternatives, and polyfill usage:
> > https://github.com/benwiley4000/array-replace
> >
> > Array replace shouldn't be considered an across-the-board substitute for
> > Array.prototype.splice (which mutates the array) and wouldn't be ideal
> for
> > performance critical applications handling very large arrays. It is well
> > suited for application logic where immutability is desired - a trend
> growing
> > in the Javascript community.
> >
> > Most of the application areas of object rest spread composition syntax
> (for
> > building objects, not destructuring them) are also application areas for
> > Array.prototype.replace, when your object happens to be an array.
> >
> > I'm looking forward to any feedback and I'd also love for a champion to
> step
> > in and help, if you think this is an ok idea.
> >
> > Thanks!
> > Ben
> >
> > ___
> > 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

Array.prototype.replace

[Ben Wiley]

Hi ECMAScript folks,

I'm brand new to this process and I've drafted a proposal (and polyfill)
for a new Array.prototype.replace method. In the vein of Array concat,
String replace and the new Object rest spread, Array replace provides a way
to shallow clone an array and replace an element in a single statement.

Here's the GitHub repo, which outlines API, motivation, use cases,
alternatives, and polyfill usage:
https://github.com/benwiley4000/array-replace

Array replace shouldn't be considered an across-the-board substitute for
Array.prototype.splice (which mutates the array) and wouldn't be ideal for
performance critical applications handling very large arrays. It is well
suited for application logic where immutability is desired - a trend
growing in the Javascript community.

Most of the application areas of object rest spread composition syntax (for
building objects, not destructuring them) are also application areas for
Array.prototype.replace, when your object happens to be an array.

I'm looking forward to any feedback and I'd also love for a champion to
step in and help, if you think this is an ok idea.

Thanks!
Ben
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss