Re: function invocation with just commas for explicit undefined optional arguments in the middle
I'm not sure I find the reduced readability argument compelling on this
one. The alternatives suggested (throwaway variables or crowding meaningful
parameters with `undefined`) don't get clean scores on that front either,
IMO.
Simply eliding a parameter seems like a nice example of terse/expressive
syntax. /2-cents
On Wed, Oct 30, 2019 at 4:21 PM Cyril Auburtin
wrote:
> I proposed it a long time ago
> https://esdiscuss.org/topic/ignoring-arguments
>
> but I agree with Tab Atkins nowadays, it would hurt readability
>
> On Wed, Oct 30, 2019 at 9:34 AM Naveen Chawla
> wrote:
>
>> I tend to agree and one thing I like in good code is "glanceability" -
>>
>> the ability to "glance" and see what's going on.
>>
>> If I have
>>
>> doStuff(bar,, foo,, far)
>>
>> vs
>>
>> doStuff(bar, foo,, far)
>>
>> they don't look too different, but really they are. I normally break
>> params into separate lines so I wouldn't have this problem, but there's the
>> risk overall.
>>
>> I like that a motivational factor for introducing a language feature is
>> "reducing the likelihood of bugs", and in my mind this one seems to very
>> slightly increase it
>>
>> On Tue, 29 Oct 2019 at 18:49, Tab Atkins Jr.
>> wrote:
>>
>>> On Tue, Oct 29, 2019 at 9:06 AM manuelbarzi
>>> wrote:
>>> > ```
>>> > fun('a', 'b',, 'd',, 'f')
>>> > ```
>>>
>>> While this does technically match up with arrays, I find the the array
>>> behavior unreadable and unintuitive (especially with the exception for
>>> the final comma), and I'd prefer that syntax quirk not spread to other
>>> list-like syntax constructs.
>>>
>>> Passing `undefined` is simply and easy enough; if it's too long you
>>> can shave off three characters by spelling it `void 0`. Or put a `var
>>> _;` at the top of your script and use that.
>>>
>>> ~TJ
>>> ___
>>> 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
>
--
Jeremy Martin
661.312.3853
@jmar777 <https://twitter.com/jmar777> / @j <https://stream.live/j>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Proposal: 1) Number (integer or decimal) to Array 2) Array to Number (integer or decimal)
any proposal is useful.
>
> The array format is a simple data structure. Can be converted to JSON; can
> be extended to include a description of each digit that is a user gets or
> sets; e.g.,
>
> n[0].description // {digit: 1, place: 'hundreds', decimalSibling:
> true, ...etc.}
>
> With respect, your test cases confuse the issue more than they clarify.
>> Questions on how you'd use this structure aside (which are still
>> important), your test cases *don't actually produce a structure in which
>> digits are accessible by nth index* (e.g., the 0-grouping behavior).
>
>
> Not sure what you mean? What are you confused about relevant to the test
> cases? The code at the OP includes 1) the original proof of concept; 2)
> code by Stack Overflow user Shidersz
> <https://stackoverflow.com/users/10366495/shidersz> which fixed two bugs
> in the original code. Yes, the code at the OP does produce the expected
> result.
>
> You are misconstruing the proposal. The code already returns the expected
> result. Do not ask for approval for anything. Just do and let the aftermath
> settle to its own level.
>
> The proposal is asking you people who claim to be specification authors to
> _name_ each element of the resulting array, for consistency, again, the
> example
>
> var n = numberToArray(100.00015); // [1, 0, 0, 0.0001, 5]
>
> as an array users obviously do not have additional data about the values
> in the array. What do you call the 0 at index 1? What do you call the 5 at
> index 4?
>
> Before incorporating the output into an object, similar to
> Intl.NumberFormat.prototype.formatToParts - and including the original
> array in the object, or Map - am asking for standardization of the names of
> each digit in a _spread_ number in an array.
>
> Number to array, array to number is just the first part of the procedure.
> The part relevant to actually _naming_ the parts, for disambiguation, is
> what propose here. If you are not interested, that is fine. Do not
> necessarily need you to do anything. Will do for self as have and continue
> to do independently, and name the discrete portions of the number
> arbitrarily, without your input.
>
> Again, if you do not gather that this proposal is similar to and extends
> the functionality of Intl.NumberFormat.prototype.formatToParts, perhaps you
> should try to use that feature, note that "integer" and "fraction" and
> "minusSign" are possible return values at output, then lobby for the
> feature to be removed from Ecma specification, for the same reasons that
> you are citing at this proposal, which would then make your
>
> premise that I'm challenging
>
>
> consistent. Otherwise, you have only offered standard western academic
> conjecture, which can be set aside where an individual is not beholden to
> or reliant on western academic conjecture to proceed with anything they
> decide to.
>
> With respect,
>
>
> "respect" is irrelevant to the proposal. Do not need or care about what
> you consider "respect". You cannot offend this user.
>
> On Tue, Mar 12, 2019 at 3:46 PM Jeremy Martin wrote:
>
>> The proposal seeks to standardize the naming conventions of number to
>>> array and array to number, including decimals.
>>
>>
>> You're describing the hammer. When we ask for the motivation for your
>> proposal, we're trying to understand *what you want to do with the
>> hammer*, and that needs to be something more generalized than
>> programmatically recreating an interesting number sequence (and more
>> explicitly stated than whatever we are to infer from your test cases).
>>
>> In our repeated attempts to suss that out, this seems to be your clearest
>> description:
>>
>> It is simpler to have the ability to add, subtract, divide, or otherwise
>>> manipulate individual nth indexes of an integer or decimal represented as
>>> an array of integers potentially containing one decimal than trying to
>>> perform the same mathematical operations on a number in JavaScript
>>> (essentially broken in JavaScript due to the floating-point number issues).
>>
>>
>> That's the premise that I'm challenging. Why is it simpler, and how does
>> it, *in any appreciable way*, improve upon whatever you're asserting is
>> "broken"? As specified by your proposal, your input and output parameters
>> are Floats, which means that the precision limitations of floating point
>> numbers remain unaddressed.
>>
>> All of the test cases used at the code which fixed the bugs in the proof
>>> of concept at the original post output the expect
Re: Proposal: 1) Number (integer or decimal) to Array 2) Array to Number (integer or decimal)
> > The proposal seeks to standardize the naming conventions of number to > array and array to number, including decimals. You're describing the hammer. When we ask for the motivation for your proposal, we're trying to understand *what you want to do with the hammer*, and that needs to be something more generalized than programmatically recreating an interesting number sequence (and more explicitly stated than whatever we are to infer from your test cases). In our repeated attempts to suss that out, this seems to be your clearest description: It is simpler to have the ability to add, subtract, divide, or otherwise > manipulate individual nth indexes of an integer or decimal represented as > an array of integers potentially containing one decimal than trying to > perform the same mathematical operations on a number in JavaScript > (essentially broken in JavaScript due to the floating-point number issues). That's the premise that I'm challenging. Why is it simpler, and how does it, *in any appreciable way*, improve upon whatever you're asserting is "broken"? As specified by your proposal, your input and output parameters are Floats, which means that the precision limitations of floating point numbers remain unaddressed. All of the test cases used at the code which fixed the bugs in the proof of > concept at the original post output the expected result. With respect, your test cases confuse the issue more than they clarify. Questions on how you'd use this structure aside (which are still important), your test cases *don't actually produce a structure in which digits are accessible by nth index* (e.g., the 0-grouping behavior). On Tue, Mar 12, 2019 at 2:13 AM guest271314 wrote: > With respect, it's still not clear how you want to interact with the array >> of values once you've destructured a Float into your array format. > > If all you have is an array of single-digit numbers that represent the >> values in the tenths/hundredths/etc. positions of the source number, how >> does this actually circumvent the challenges of representing Decimal values >> that aren't exactly representable as a Float? > > > It is not clear how your examples of adding specific values in JavaScript > are relevant to the proposal. > > All of the test cases used at the code which fixed the bugs in the proof > of concept at the original post output the expected result. > > If you have more test cases, number or decimal, to suggest for input > relevant to the code at the original proposal, number to array, array to > number, kindly post those tests cases listing input and expected output. > > The proposal does not seek to solve all JavaScript number issues. > > The proposal seeks to standardize the naming conventions of number to > array and array to number, including decimals. An array is the simplest > form of structured output. An object of key, value pairs (similar to > Intl.NumberFormat, with JavaScript numbers instead of strings) can also be > utilized for each of the digits of integer and decimal (fraction), if any. > > > > On Mon, Mar 11, 2019 at 4:33 PM Jeremy Martin wrote: > >> With respect, it's still not clear how you want to interact with the >> array of values once you've destructured a Float into your array format. >> >> If all you have is an array of single-digit numbers that represent the >> values in the tenths/hundredths/etc. positions of the source number, how >> does this actually circumvent the challenges of representing Decimal values >> that aren't exactly representable as a Float? >> >> To illustrate this challenge, let's use the classic example we've all >> seen hundreds of times: >> >> > .1 + .2 >> 0.30004 >> >> For a long time, all the reading I would do about *why* this produced a >> weird result would *sort* of make sense and *sort* of confuse me. That >> is, I could understand *why* 3/10ths isn't representable as a Float, but >> then I would get confused by the fact that I could type `.3` into a REPL, >> and it would *actually work *(??!): >> >> > .3 >> 0.3 >> >> I mean, who's lying? How come `.3` works fine when I just type it >> straight in, and `.1 + .3` works just fine, but there's just these >> specific cases like `.1 + .2` where all of a sudden `.3` decides not to >> be representable again? >> >> I admit this is conjecture, but maybe that's part of the confusion >> motivating this proposal? And maybe the idea is that if we can break `.1` >> and `.2` into some sort of an array structure (e.g., [0, 1] and [0, 2]), then >> we can add the individual parts as integers (giving us something like [0, >> 3]) which we can then just convert back
Re: Proposal: 1) Number (integer or decimal) to Array 2) Array to Number (integer or decimal)
integer:[0]},
>>>>> ...args.filter(({type}) => type === "integer" || type === "fraction" ||
>>>>> type === "minusSign").map(({type, value}) => ({[type === "minusSign" ?
>>>>> "sign" : type]: type !== "minusSign" ? [...value].map(Number) : -1})));
>>>>> }
>>>>>
>>>>> let number = -123;
>>>>>
>>>>> let formatter = new Intl.NumberFormat('en-US');
>>>>>
>>>>> let res = formatter.formatToParts(number);
>>>>>
>>>>> formatNumberParts(res);
>>>>>
>>>>> If the concern is that the proposal would not be useful, consider what
>>>>> you would *name* various uses of Math.trunc and remainder operator
>>>>> used at your message?
>>>>>
>>>>>
>>>>> On Sun, Mar 10, 2019 at 3:58 PM Tab Atkins Jr.
>>>>> wrote:
>>>>>
>>>>>> On Sat, Mar 9, 2019 at 11:10 AM Felipe Nascimento de Moura
>>>>>> wrote:
>>>>>> >
>>>>>> > Personally, I don't think it would be THAT useful...
>>>>>> > but...I think there is something behind this proposal that makes
>>>>>> sense.
>>>>>> >
>>>>>> > I do believe it could be useful for developers to have an easier
>>>>>> access to number parts or characteristics.
>>>>>> > Perhaps something like:
>>>>>> >
>>>>>> > const i = 1234.567;
>>>>>>
>>>>>> Can you provide a scenario in which these would do something useful,
>>>>>> such that it would be worth adding them over just using the math
>>>>>> operations that already exist?
>>>>>>
>>>>>> > console.log( i.float ); // 567
>>>>>>
>>>>>> i % 1
>>>>>>
>>>>>> (If you really wanted this as an integer, it's not well-founded; .567
>>>>>> isn't exactly representable as a double, so JS doesn't know that you
>>>>>> "meant" it to have only three digits after the decimal point, and thus
>>>>>> want 567 as the answer. You'll instead get some very very large
>>>>>> integer that *starts with* 567, followed by a bunch of zeros, followed
>>>>>> by some randomish digits at the end.)
>>>>>>
>>>>>> > console.log( i.abs ); // 1234
>>>>>>
>>>>>> Math.trunc(i)
>>>>>>
>>>>>> > console.log( i.thousands ); // 1
>>>>>>
>>>>>> Math.trunc(i / 1000)
>>>>>>
>>>>>> > console.log( i.million ); // 0
>>>>>>
>>>>>> Math.trunc(i / 1e6)
>>>>>>
>>>>>> > console.log( i.hundred ); // 2
>>>>>>
>>>>>> Math.trunc(i / 100) % 10
>>>>>>
>>>>>> > console.log( i.hundreds ); // 12
>>>>>>
>>>>>> Math.trunc(i / 100)
>>>>>>
>>>>>> > console.log( i.ten ); // 2
>>>>>>
>>>>>> Math.trunc(i / 10) % 10
>>>>>>
>>>>>> > console.log( i.tens ); // 123
>>>>>>
>>>>>> Math.trunc(i / 10)
>>>>>>
>>>>>> > console.log( i.tenth ); // 5
>>>>>>
>>>>>> Math.trunc(i % 1 * 10) % 10
>>>>>>
>>>>>> > console.log( i.tenths ); // 5
>>>>>>
>>>>>> Math.trunc(i % 1 * 10)
>>>>>>
>>>>>> > console.log( i.hundredth ); // 6
>>>>>>
>>>>>> Math.trunc(i % 1 * 100) % 10
>>>>>>
>>>>>> > console.log( i.hundredths ); // 56
>>>>>>
>>>>>> Math.trunc(i % 1 * 100)
>>>>>>
>>>>>>
>>>>>> Some of these are easy to remember and use; others take some thinking
>>>>>> to deploy. But the question is still "what would someone use this
>>>>>> information for?", such that the benefit to developers is worth the
>>>>>> cost to all parties involved (spec writers, implementors, testers, and
>>>>>> then developers having to navigate a larger stdlib).
>>>>>>
>>>>>> ~TJ
>>>>>> ___
>>>>>> 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
>
--
Jeremy Martin
661.312.3853
@jmar777 <https://twitter.com/jmar777> / @j <https://stream.live/j>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Proposal: 1) Number (integer or decimal) to Array 2) Array to Number (integer or decimal)
Is it fair to suggest that transforming numeric values to and from arrays isn't the ultimate goal of this proposal? Based on your examples, it seems there are specific manipulations you would like to be able to perform to numeric values, and your contention is that these manipulations would be more straightforward if various components of that value (i.e., the individual digits, the decimal location, and the sign) were represented in a "more structured" way (i.e., an array). Is that much a fair assessment? If that's the case, could you expand on the specific manipulations themselves? Preferably something more explicit and scoped than linking out to one of these external references, if possible. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Proposal: 1) Number (integer or decimal) to Array 2) Array to Number (integer or decimal)
It's entirely possible that I'm being thick here, but can you expand on the use case? - The initial link that you posted results in a code challenge that was voted down to a negative score as a result of ambiguity in the challenge description, and... - the two expressions you provided are already valid JavaScript. - I'm also confused as to why we'd want `1.074` to convert to `[1.0, 7, 4]`. How is that different from, say, `1.74` also converting to `[1, 7, 4]` (given that `1 == 1.0`)? Going back to our request for a "real world" use case, we're asking you to provide an example of something that you'd want to do that has value external to the proposal itself. That is, if I proposed a `toX()` method that always converted the receiver to the character "X", I would need to provide a real world justification beyond "it's easier to convert things into the letter X". So, again, what is a real world utility of this transformation? On Thu, Mar 7, 2019 at 5:22 PM guest271314 wrote: > Have you read the proposal, and the first response to your inquiry? It is > simpler to have the ability to add, subtract, divide, or otherwise > manipulate individual nth indexes of an integer or decimal represented as > an array of integers potentially containing one decimal than trying to > perform the same mathematical operations on a number in JavaScript > (essentially broken in JavaScript due to the floating-point number issues). > > Will re-post a use case, again > ~~(128.625*9*1.074)//1243 > ~~(128.625*9*1.144)//1324 where if the requirement is to increment the > decimal portion of 1.074 or 1.144 if the decimal is first converted to an > array, we can use array methods to tests the matches we are looking for. > For example, [1.0, 7, 4] > > representation of 1.074 allows each of the portions of the number to be > adjusted independently. Since we have previously defined a .toNumber() > Array method we know we can get the value of the array as a JavaScript > number. > > On Thu, Mar 7, 2019 at 10:12 PM Jeremy Martin wrote: > >> By "real world" we mean somewhere outside of a code challenge or >> similarly low utility program context. >> >> You mentioned statistics, for example. Can you reference a specific >> example from that domain where these methods would offer an advantage? >> >> On Thu, Mar 7, 2019, 5:05 PM guest271314 wrote: >> >>> Not sure what you mean by "real world" use case. Described at least one >>> use case at the proposal. Statistics; graphs; number and integer >>> manipulation using indexes of arrays with ability to convert manipulated >>> array back to number. >>> >>> On Thu, Mar 7, 2019 at 9:56 PM Naveen Chawla >>> wrote: >>> >>>> What is the real world use case, presuming it's not just an academic >>>> exercise >>>> >>>> On Thu, 7 Mar 2019, 9:08 pm guest271314, wrote: >>>> >>>>> Ability to adjust *nth* digit of an integer or decimal by adjusting >>>>> decimal or integer at *nth* index of array, to try to solve OEIS >>>>> A217626 oeis.org/A217626 directly, for example >>>>> ~~(128.625*9*1.074)//1243 >>>>> ~~(128.625*9*1.144)//1324 >>>>> where the decimal portion can be manipulated by referencing the index >>>>> of an array, then converting the array back to a number. >>>>> >>>>> On Thu, Mar 7, 2019 at 8:55 PM Jeremy Martin >>>>> wrote: >>>>> >>>>>> Can you explain the motivation for this proposal? >>>>>> >>>>>> At first blush, this seems like an incredibly arbitrary pair of value >>>>>> conversion utilities. Are there real world applications for this? >>>>>> >>>>>> On Thu, Mar 7, 2019 at 3:43 PM guest271314 >>>>>> wrote: >>>>>> >>>>>>> >>>>>>> >>>>>>> -- Forwarded message - >>>>>>> From: guest271314 >>>>>>> Date: Thu, Mar 7, 2019 at 8:35 PM >>>>>>> Subject: Proposal: 1) Number (integer or decimal) to Array 2) Array >>>>>>> to Number (integer or decimal) >>>>>>> To: >>>>>>> >>>>>>> >>>>>>> Original concept: Integer or decimal to array and array to decimal >>>>>>> or integer https://codegolf.meta.stackexchange.com/a/17223 >>>>>>> >>>>>>> Proof of concept (with bugs) >&g
Re: Proposal: 1) Number (integer or decimal) to Array 2) Array to Number (integer or decimal)
By "real world" we mean somewhere outside of a code challenge or similarly
low utility program context.
You mentioned statistics, for example. Can you reference a specific example
from that domain where these methods would offer an advantage?
On Thu, Mar 7, 2019, 5:05 PM guest271314 wrote:
> Not sure what you mean by "real world" use case. Described at least one
> use case at the proposal. Statistics; graphs; number and integer
> manipulation using indexes of arrays with ability to convert manipulated
> array back to number.
>
> On Thu, Mar 7, 2019 at 9:56 PM Naveen Chawla
> wrote:
>
>> What is the real world use case, presuming it's not just an academic
>> exercise
>>
>> On Thu, 7 Mar 2019, 9:08 pm guest271314, wrote:
>>
>>> Ability to adjust *nth* digit of an integer or decimal by adjusting
>>> decimal or integer at *nth* index of array, to try to solve OEIS
>>> A217626 oeis.org/A217626 directly, for example
>>> ~~(128.625*9*1.074)//1243
>>> ~~(128.625*9*1.144)//1324
>>> where the decimal portion can be manipulated by referencing the index of
>>> an array, then converting the array back to a number.
>>>
>>> On Thu, Mar 7, 2019 at 8:55 PM Jeremy Martin wrote:
>>>
>>>> Can you explain the motivation for this proposal?
>>>>
>>>> At first blush, this seems like an incredibly arbitrary pair of value
>>>> conversion utilities. Are there real world applications for this?
>>>>
>>>> On Thu, Mar 7, 2019 at 3:43 PM guest271314
>>>> wrote:
>>>>
>>>>>
>>>>>
>>>>> -- Forwarded message -
>>>>> From: guest271314
>>>>> Date: Thu, Mar 7, 2019 at 8:35 PM
>>>>> Subject: Proposal: 1) Number (integer or decimal) to Array 2) Array to
>>>>> Number (integer or decimal)
>>>>> To:
>>>>>
>>>>>
>>>>> Original concept: Integer or decimal to array and array to decimal or
>>>>> integer https://codegolf.meta.stackexchange.com/a/17223
>>>>>
>>>>> Proof of concept (with bugs)
>>>>>
>>>>> function numberToArray(n) {
>>>>>
>>>>> if (Math.abs(n) == 0 || Math.abs(n) == -0) {
>>>>> return [n]
>>>>> }
>>>>>
>>>>> const r = [];
>>>>>
>>>>> let [
>>>>> a, int = Number.isInteger(a), d = g = [], e = i = 0
>>>>> ] = [ n || this.valueOf()];
>>>>>
>>>>> if (!int) {
>>>>> let e = ~~a;
>>>>> d = a - e;
>>>>> do {
>>>>> if (d < 1) ++i;
>>>>> d *= 10;
>>>>> } while (!Number.isInteger(d));
>>>>> }
>>>>>
>>>>> for (; ~~a; r.unshift(~~(a % 10)), a /= 10);
>>>>>
>>>>> if (!int) {
>>>>> for (; ~~d; g.unshift(~~(d % 10)), d /= 10);
>>>>> g[0] = g[0] * (1 * (10 ** -i))
>>>>> r.push(...g);
>>>>> }
>>>>>
>>>>> return r;
>>>>> }
>>>>> function arrayToNumber(a) {
>>>>> if ((Math.abs>>>> class="gmail-m_2662878951066317968m_7497912379499730396gmail-m_-49591865513921258gmail-m_191674293613409874m_-1290191079188355796gmail-pun"
>>>>>
>>>>> style="margin:0px;padding:0px;border:0px;font-style:inherit;font-variant:inherit;font-weight:inherit;font-stretch:inherit;line-height:inherit;font-family:inherit;
>>>>>
>>>>>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: something wrong about generator
The `yield *` expression actually *evaluates* to the final value of the
delegated generator (i.e., the final value when *done* is *true*).
In other words, if you modified your second generator in your example to
the following:
function* b() {
const result = yield* a();
console.log('THE RESULT', result);
}
...you will see that `result` is equal to "end". So, to reiterate (pun not
intended, but intentionally left intact), the final returned value of the
delegated generator is not yielded from the parent generator, but is
instead used as the value of the `yield *` expression itself.
Hope that helps!
On Sun, May 6, 2018 at 11:44 AM, Vic9 <vic99...@yandex.ru> wrote:
> >or it need to return {value: {value: "end", done: true}, done: true}
>
> this case is supported, seems, if to use:
>
> function* b() {
> return yield* a()
> }
>
> ___
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
--
Jeremy Martin
661.312.3853
@jmar777 <https://twitter.com/jmar777> / @j <https://stream.live/j>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Proposal: spread assignment operator
By way of context, some similar ideas have been previously discussed:
-
https://esdiscuss.org/topic/picking-deconstructing-properties-into-object-literals
-
https://esdiscuss.org/topic/destructuring-an-object-into-a-new-object-like-underscore-pick-but-esier
-
https://esdiscuss.org/topic/extended-dot-notation-pick-notation-proposal
FWIW, I actually do like the idea of being able to syntactically "reshape"
one object or array directly into another, and there's probably even a
cowpath argument to be made on the basis of so many `pick()`, `omit()`,
etc. implementations out there. On the other hand, per Isiah's comments,
we're at least 90% there already with Object.assign(), so it seems like the
value proposition could/should be developed a bit more on this.
On Wed, Apr 25, 2018 at 12:29 PM, Arutyunyan Artyom <arta...@ya.ru> wrote:
>
> I think it can be looks like: https://gist.github.com/artalar/
> ea8512546a3675648615a25e846096a6
>
> 25.04.2018, 18:58, "Isiah Meadows" <isiahmead...@gmail.com>:
>
> It doesn't. But with objects, it's not a cheap operation to simply
> duplicate, and they aren't normally immutable like primitives. Furthermore,
> why is it for objects, not arrays?
>
> (I'm pushing that second question as a point of potential confusion -
> remember the user.)
>
> On Wed, Apr 25, 2018, 11:45 Arutyunyan Artyom <arta...@ya.ru> wrote:
>
> spread assignment not mutate, it reassign, like "+=" and other.
>
> if (
> ('a = {...a,...b}'.length > 'a ...= b'.length) === ('n = n+1'.length > 'n
> += 1'.length)
> ) { console.log('why "addition assignment" is necessary, but "spread
> assignment" is not?'); }
>
>
>
>
> 25.04.2018, 18:21, "Isiah Meadows" <isiahmead...@gmail.com>:
>
> Note: `Object.assign` mutates its first argument and (with only obscure
> caveats) does exactly this. Not sure syntax is necessary here.
>
> Oh, and arrays also have the common idiom `array.push(...values)` (but
> they could use an `Array.prototype.pushAll` to avoid polluting arguments
> lists).
>
> On Wed, Apr 25, 2018, 09:24 Артём Арутюнян <arta...@ya.ru> wrote:
>
> I propose *spread assignment operator*:
>
> *var obj = { test1: 1 };*
> *var anotherObj = { test2: 2 };*
> *obj ...= { test2: 2 }; // == (obj = { ...obj, ...anotherObj })*
> *// { test1: 1, test2: 2 }*
>
> I'm surprised it wasn't in the original implementation
> ___
> 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
>
>
--
Jeremy Martin
661.312.3853
@jmar777 <https://twitter.com/jmar777> / @j <https://stream.live/j>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: EcmaScript Proposal - Promised functions
npm.js#L112 - "npm/npm.js > at v5.8.0 · npm/npm" > [2] https://travis-ci.org/npmdoc/node-npmdoc-npm/builds/365262668#L1300 - > "Travis CI - Test and Deploy Your Code with Confidence" > [3] https://github.com/kaizhu256/node-apidoc-lite/ > blob/2017.4.12/lib.apidoc.js#L1019 - “node-apidoc-lite/lib.apidoc.js at > 2017.4.12" > > > > ___ > es-discuss mailing list > es-discuss@mozilla.org > https://mail.mozilla.org/listinfo/es-discuss > > -- Jeremy Martin 661.312.3853 @jmar777 <https://twitter.com/jmar777> / @j <https://stream.live/j> ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: FW: javascript vision thing
> >> exist doesn't obligate you to use them, and they don't hurt you in any > >> way if you don't. Also, complaints of a person's or group's choice of > >> idiom do *not* belong on this list whatsoever. Leave that crap to a > >> private message, a blog post (if it's a group), or whatever. > >> 3. JavaScript "classes" are not technically class-based OOP, and TC39 > >> members have acknowledged this in blog posts. It's 99% sugar over the > >> existing prototype-based model, just with easier native subclassing. > >> You could in theory replicate this in the rest of the language with a > >> combination of `Object.defineProperty`, `Object.setPrototypeOf`, > >> `new.target`, and existing ES5. > >> - > >> > >> Isiah Meadows > >> m...@isiahmeadows.com > >> > >> Looking for web consulting? Or a new website? > >> Send me an email and we can get started. > >> www.isiahmeadows.com > >> > >> > >> On Thu, Nov 2, 2017 at 4:32 PM, doodad-js Admin <dooda...@gmail.com> > >> wrote: > >> > > >> > -Original Message- > >> > From: Claude Petit [mailto:p...@webmail.us] > >> > Sent: Thursday, November 02, 2017 4:24 PM > >> > To: 'kai zhu' <kaizhu...@gmail.com>; 'es-discuss' < > >> es-discuss@mozilla.org> > >> > Subject: RE: javascript vision thing > >> > > >> > For mostly real OOP under JS, please see my project (doodad-js). But I > >> can't warranty its future without a custom language because nobody on > >> TC39 > >> want to works along-side with me on that project, and they are making > >> their > >> own supposed "classes" which are not. > >> > > >> > -Original Message- > >> > From: kai zhu [mailto:kaizhu...@gmail.com] > >> > Sent: Wednesday, November 01, 2017 11:43 PM > >> > To: es-discuss <es-discuss@mozilla.org> > >> > Subject: javascript vision thing > >> > > >> > any thoughts? i'll break the ice with a quora question i recently > >> answered > >> > > >> > quora question: > >> >> Why is JavaScript so hated? > >> > > >> > answer posted: > >> >>the primary reason is because traditional oop skills gained from > >> c#/c++/java/python/etc translate poorly to javascript. > >> >> > >> >>in javascript, class-instantiated objects are inferior to > >> >> plain-objects, > >> because plain-objects come with JSON.stringify/JSON.parse baked-in, > while > >> classes require needless extra serialization/deserialization routines > >> which > >> can easily double your codebase or more (as real-world javascript-code > is > >> heavily i/o based). i would say many people burn-out from > >> frontend-programming because they can’t cope with debugging all the i/o > >> edge-cases serializing/deserializing their custom classes. > >> >> > >> >>javascript and frontend-programming is essentially about efficiently > >> managing the program-state like a baton, constantly passing it > >> back-and-forth between the browser’s ui and various backend-servers / > >> persistent-storage. plain json-objects utilizing idiot-proof > >> JSON.stringify/JSON.parse, are naturally better at this baton-passing > >> business than writing classes with custom serializers. > >> > > >> > > >> > > >> > there's currently a civil war going on in frontend-development, > between > >> those who don't want to deal with writing extra class-based > >> serializers/deserializers and those who do. these 2 different design > >> patterns have incompatible styleguides that often break web-projects > when > >> people try to mix-and-match both together. i don't have a simple > >> solution > >> to this issue, but tc39 should be made aware of it as they try to > >> formulate > >> a javascript vision that doesn't alienate frontend-development. > >> > > >> > -kai > >> > > >> > > >> > > >> > --- > >> > This email has been checked for viruses by AVG. > >> > http://www.avg.com > >> > > >> > ___ > >> > 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 > -- Jeremy Martin 661.312.3853 @jmar777 <https://twitter.com/jmar777> / @j <https://stream.live/j> ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Array.prototype.remove(item)
I'm not sure where the "don't break the web" threshold is set at (or how that gets evaluated), but I do see a lot of matches for "Array.prototype.remove" on GitHub, at least: https://github.com/search?l=JavaScript=%22Array.prototype.remove%22=Code=%E2%9C%93 There's also an old blog post by John Resig with an example implementation ( https://johnresig.com/blog/javascript-array-remove), so I'm not sure if that gave rise to any significant adoption or not. I like the proposal in general, though - just throwing this out there in case other names should be considered (maybe `discard`?). On Sat, Nov 11, 2017 at 3:56 PM, Alexander Jones <a...@weej.com> wrote: > Small Sets could maybe be represented without the tree? > > And everything you say about SIMD could be done too when the set has a > viable homogeneous type. > > > > On Fri, 10 Nov 2017 at 14:26, T.J. Crowder <tj.crowder@farsightsoftware. > com> wrote: > >> On Fri, Nov 10, 2017 at 2:17 PM, Isiah Meadows >> <isiahmead...@gmail.com> wrote: >> > Inline. (Hindsight, should've included this in the previous email) >> >> Good deal, that's the kind of thing I was thinking would strengthen the >> argument. >> >> I think you may have meant to have more after *"In nearly every virtual >> DOM library, in >> most , the core involves..."* ? (Ignore this if the rest of that sentence >> wasn't important.) >> >> -- 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 > > -- Jeremy Martin 661.312.3853 @jmar777 <https://twitter.com/jmar777> / @j <https://stream.live/j> ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Question of the Day: What about all this asynchrony?
I don't represent TC39, and I don't like adding so much noise to this list, so this will be my last reply on the topic. There's nothing fundamentally wrong with what you want, but you're barking up the wrong tree to get it: > This (not concerning themselves with the end users experience) is a > mistake (an opinion). This group is acutely aware of, and concerned with, the end user experience. As previously stated, many (if not most) of the members actively contribute from their personal time to assist in these areas. But that *doesn't* mean that as a committee they are obligated to all aspects of the developer experience. I understand, but we can always do better (nothing is perfect). And that > applies even with scarce resources. It could be better. I want to help. Whether scarce or abundant, when the "resource" is someone else's time and effort, you simply don't have any claim to it. If you want to help, then do it! Publicly shaming people who are *already* helping, simply because they're not helping where and how you want them to, is not ok, though. If I get time, I might head back there. Honestly, though, I'm looking for > simple summaries as opposed to exhaustive histories. Give me the > takeaways. Save me some time. I wasn't going to respond until I read this part. Someone has already spent hours upon hours researching and compiling a useful resource (*A General Theory of Reactivity*), and instead of reading it, you're demanding *more* time from complete strangers to distill it into the exact level of verbosity that *you* want. That's not ok, and not what this mailing list is for. People in this list dedicate countless hours to save other people time, but their efforts aren't at your beck and call. Visual development is inevitable. Even if I am 100% in support of that statement, that doesn't mean that the visual development facilities are a part of the language itself. Again, I'm not trying to say that you have bad ideas, just that you've found the wrong mailing list for some of these. There's no need for a governing body that's not doing their job. The abundance of new features in the language is prima facie evidence that they are doing their job. Their job just isn't what you want it to be. Yet, many of the people on this list work on those runtime implementations > (Chrome, node, whatever). I'm reaching out to anyone who will listen. That's fine, there's no harm in trying. But when the people you reach out to suggest that it's off topic or out of scope for the venue you've chosen, then it's not fine to start ranting and publicly shaming them. The problem is real. The conclusion: "won't fix". Yes, there is a real problem (at least a challenge, anyway). But the existence of a problem isn't a license to demand a solution from whomever you deem responsible. Even when members in this list have tried to offer some help, primarily by referencing relevant reading material, those efforts have been rejected because we didn't create the cliff notes for you. Again, I'm not the authority on what is or isn't within scope of this list, but the sum total of these demands, shaming, and wandering subject matter do not seem to be appropriate here. On Wed, Nov 8, 2017 at 1:05 PM, Michael Lewis <m...@lew42.com> wrote: > > > On Wed, Nov 8, 2017 at 10:00 AM, Jeremy Martin <jmar...@gmail.com> wrote: > >> Michael, >> >> You are not alone in your frustrations. Many of your points are valid, >> have been voiced before, and will no doubt be voiced again. No one on here >> is unsympathetic to this, and many members of TC39, as well as other >> community members, dedicate significant amounts of time, freely, to >> educational resources. >> > > Thanks, it's a relief to finally hear. This was definitely *not* the > impression that I've gotten so far. I've essentially heard, "there is no > problem, what are you talking about?" > > >> >> Lambasting TC39 for not formalizing and centralizing these educational >> resources -- a task that exists far outside of their charter -- is not >> productive. >> > > This (not concerning themselves with the end users experience) is a > mistake (an opinion). The JavaScript community would be better off if more > care were given to this aspect (not an opinion). > > >> >> The list of useful resources out there is pretty extensive, and as you've >> pointed out, that can have a downside if you don't know where to go. If >> it's helpful, here's a non-canonical overview of some of the more useful >> ones, though: >> >> *For a one-stop shop:* >> >> MDN (https://developer.mozilla.org/en-US/docs/Web/JavaScript). If you >> want a single destination, choose this one. It has introductory material, >> beginner, intermed
Re: Question of the Day: What about all this asynchrony?
nowledge that this committee has the power (responsibility?) to fix that >>>> problem <https://esdiscuss.org/topic/web-docs>. To make learning >>>> simpler, easier, etc. It could start with an official blog. There are too >>>> many scattered resources. Too much conflicting advice, and not an official >>>> direction. >>>> >>>> If Babel is here to stay - and transpiling custom syntax into official >>>> syntax is going to proliferate, this problem will only get worse. >>>> >>>> This has to do with leadership - there doesn't seem to be a strong >>>> presence leading the pack. There are millions of developers scrambling to >>>> make sense of all this stuff, and the best resources we have are the >>>> continuous stream of blog posts that are constantly introducing new things, >>>> and often create more questions than answers. >>>> >>>> It's clear to me that the people in this mailing list tend to stay at >>>> the cutting edge. You all read about the latest immediately when it's >>>> released. It makes sense to you, and there is no problem. The "rest of >>>> us" who struggle just aren't doing it right. >>>> >>>> On Tue, Nov 7, 2017 at 6:09 PM, Felipe Nascimento de Moura < >>>> felipenmo...@gmail.com> wrote: >>>> >>>>> Hi. >>>>> >>>>> Michael, the JavaScript (and Web in general) communities are very open >>>>> and always queen to help. >>>>> I just think you hit the wrong mailing list to discuss all that. >>>>> >>>>> For new comers, indeed, there is plenty to work on, practice and >>>>> study. But keep in mind that many of those features came from different >>>>> languages and technologies. >>>>> And there are a lot of conferences, meetups, groups, slack channels, >>>>> newsletters, articles, videos...tons of content out there :) >>>>> >>>>> Trying to answer your question. >>>>> I understand the feeling you are having, but think it this way... >>>>> - Asynchronous code opens doors for possible gains in performance. >>>>> Many improvements have only been possible due to this asynchronicity. >>>>> - Async code helps you modulate/split your code. If your are an >>>>> organized person, it will be good...otherwise, things can get messy! >>>>> - Async code nowadays can be dealt with, as if it was sync (using >>>>> async await), the other way around was a problem! Many times you needed >>>>> something asynchronous and had to create layers on top of it. >>>>> - Async allows new APIs. For example, Web workers and Service Workers. >>>>> They simply wouldn't be possible if not by asynchronous ways. >>>>> - Creating async APIs allows developers to explore and use your API in >>>>> different ways...also, if your code is well organized, it has an easier >>>>> maintanence. >>>>> - APIs related to interoperability and usability also benefit from >>>>> this. Let's say, you need a user permission to do something and have to >>>>> way >>>>> for the user to agree with it. Or maybe you ware waiting for another app >>>>> to >>>>> answer with the result from something else, like a picture or a share(from >>>>> shareAPI). >>>>> >>>>> As for "which" way you want to make your code async...that goes with >>>>> what you are working on. >>>>> If you are using promises, you can easily** have it working with >>>>> async/await. >>>>> Observables and promises can work together, but you will have to study >>>>> a little further to feel familiar with it. >>>>> >>>>> I hope I have helped somehow :) >>>>> >>>>> >>>>> >>>>> On Tue, Nov 7, 2017 at 8:42 PM, Michael Lewis <m...@lew42.com> wrote: >>>>> >>>>>> Making things simpler, clearer, and more visual has obvious benefits. >>>>>> >>>>>> I think I was very clear from the beginning that this was *NOT* a >>>>>> concrete proposal. And I've seen many posts on here that are not. From >>>>>> now on, I'll title my posts to more clearly indicate that *reading >>>>>> is abstract, discussion, optional.*
Re: Question of the Day: What about all this asynchrony?
:(
Apologies, I didn't intend to reply-all on that. :\
I'll keep this one public too, since I just subjected everyone to the
previous email as well.
On Tue, Nov 7, 2017 at 4:03 PM, Jeremy Martin <jmar...@gmail.com> wrote:
> Michael,
>
> You've spent a considerable amount of time putting your thoughts into
> writing, so I don't intend to be dismissive of them, but this doesn't seem
> to be the right distribution channel for whatever you're getting at.
>
> As it stands, you've thrown quite a few questions out that don't seem to
> be related to the ongoing standardization and specification process that
> this group is primarily focused on. E.g.,
>
>- Are RxJS Observables basically streams?
>- What will our children be learning in 100 years?
>- What are generators?
>- ...do they work with Promises?
>- ...do they work with streams?
>- etc.
>
> There are reams of documentation, articles, and guides that delve into
> these topics in great detail, including the excellent *General Theory of
> Reactivity* that you already mentioned. The questions you've brought up
> are all valid, and these resources will help you gain the knowledge you
> need if you still want to put a specific proposal forward -- but for now
> your points seem to awkwardly highlight that you've already identified the
> best resources to do this, but refuse to actually read them.
>
> And while es-discuss is indeed an appropriate place to solicit feedback on
> language-level proposals, the ideas you've thrown out read like an
> off-the-cuff stream of consciousness:
>
>- Promises that automatically render diagrams?
>- A GUI for loading/defining modules (somehow related to an AST)?
>- Async strings with some informal behavior around branching and
>transforms, that are someone analogous to version control, and again, a GUI
>is involved somewhere?
>- Real-time booleans with change events (but with a new definition for
>"change events" that is oddly based around a non-reactive datastructure).
>
> I made an honest attempt to make it through your posts with an eye for
> what your point is, but these simply aren't concrete or coherent enough to
> facilitate a conversation, much less be actionable.
>
> The concept of "do it now" or "do it later" is as easy as 123.
>
>
> I urge you to consider that statements like this belie that you haven't
> grappled with the subject matter enough. It frankly trivializes the topic
> beyond recognition.
>
> If you have a concrete proposal you'd like to see discussed, then a
> dedicated thread with a clear description, examples, and motivating factors
> is completely welcome. If you're looking to rant or ruminate around topics
> like Promises, Generators, Observables, Streams, etc., while simultaneously
> admitting that you aren't taking the time to understand them, then this is
> simply the wrong venue.
>
>
> On Tue, Nov 7, 2017 at 3:13 PM, Naveen Chawla <naveen.c...@gmail.com>
> wrote:
>
>> Correct, `for..of` instead of `forEach`
>>
>> On Wed, 8 Nov 2017 at 01:21 Logan Smyth <loganfsm...@gmail.com> wrote:
>>
>>> A nit, but that would have to be `for (const move of moves) await
>>> doMoveAsync()`
>>> since the `forEach` callback is a normal function.
>>>
>>> On Tue, Nov 7, 2017 at 11:47 AM, Naveen Chawla <naveen.c...@gmail.com>
>>> wrote:
>>>
>>>> ... that should be `await doMoveAsync()`
>>>>
>>>> On Wed, 8 Nov 2017 at 01:16 Naveen Chawla <naveen.c...@gmail.com>
>>>> wrote:
>>>>
>>>>> async functions create a new promise for you upon every invocation,
>>>>> which you resolve via `await`, but that's all invisible in the background.
>>>>> It's basically:
>>>>>
>>>>> async function doMovesAsync(){
>>>>> moves.forEach(
>>>>> move=>{
>>>>> doMoveAsync(); //another async function
>>>>> }
>>>>> );
>>>>> }
>>>>>
>>>>> ...so you can do regular programming, in async world. This is why I
>>>>> believe it's more powerful than observables, thereby making them
>>>>> redundant.
>>>>>
>>>>> When I say branching into multiple outputs, I do mean creating new
>>>>> data that leaves the original data untouched.
>>>>>
>>>>> On Tue, 7 Nov 2017 at 20:57 Michael Lewis <m...@lew42.com> wrote:
>>>>>
>>>>>> Also, if you've made it this
Re: Question of the Day: What about all this asynchrony?
that include >>>>>>> other async function calls, and this looks like programming with regular >>>>>>> functions, so it's trivial to set up asynchronous iteration, and/or >>>>>>> infinite event processing, etc., even without the new "async iteration" >>>>>>> proposal. >>>>>>> >>>>>>> On Tue, 7 Nov 2017 at 17:25 Michael Lewis <m...@lew42.com> wrote: >>>>>>> >>>>>>>> The email wasn't about my kids, and you don't have to read it >>>>>>>> (duh). If your time is so valuable, maybe you shouldn't be picking >>>>>>>> fights >>>>>>>> with rambling parents. >>>>>>>> >>>>>>>> Where is the list of approved topics? >>>>>>>> >>>>>>>> On Tue, Nov 7, 2017 at 5:44 AM, Bob Myers <r...@gol.com> wrote: >>>>>>>> >>>>>>>>> I'm confused. You don't have time to read "The General Theory of >>>>>>>>> Reactivity", yet (1) you have time to write this long, rambling email >>>>>>>>> about >>>>>>>>> your kids, and (2) expect people on this mailing list to spend their >>>>>>>>> valuable time reading it? >>>>>>>>> >>>>>>>>> Please stay on topic for the list. >>>>>>>>> >>>>>>>>> Bob >>>>>>>>> >>>>>>>>> On Tue, Nov 7, 2017 at 4:48 PM, Michael Lewis <m...@lew42.com> >>>>>>>>> wrote: >>>>>>>>> >>>>>>>>>> Good morning JavaScript world, >>>>>>>>>> >>>>>>>>>> Maybe I'll start my mornings with a cup of coffee, and a >>>>>>>>>> discussion prompt. We'll see how long it lasts. It's 4:39am. I >>>>>>>>>> live in >>>>>>>>>> Aurora, Illinois, about an hour outside of Chicago. My kids will >>>>>>>>>> wake up >>>>>>>>>> in an hour or two, so I don't have long, and should be working on my >>>>>>>>>> framework anyway. >>>>>>>>>> >>>>>>>>>> *So much asynchrony* >>>>>>>>>> There are callbacks, promises, async/await. We have streams in >>>>>>>>>> node.js. There are libraries like RxJS for Observables (that are >>>>>>>>>> basically >>>>>>>>>> streams?). >>>>>>>>>> >>>>>>>>>> What's the end game? What will our children's children be >>>>>>>>>> learning in 100 years? Let's reduce these pieces, distilling them >>>>>>>>>> into >>>>>>>>>> their simplest components. >>>>>>>>>> >>>>>>>>>> This <https://esdiscuss.org/topic/promises-vs-streams> is an >>>>>>>>>> interesting thread (from es-discuss) regarding asynchrony, which >>>>>>>>>> references >>>>>>>>>> Kris Kowal's General Theory of Reactivity >>>>>>>>>> <https://github.com/kriskowal/gtor/>, which is too long for me >>>>>>>>>> to dig into at this point in my life. >>>>>>>>>> >>>>>>>>>> The disappointing part, is that this community (who has mastered >>>>>>>>>> asynchrony) doesn't feel like there are any shortcomings, and so we >>>>>>>>>> continue onward without fixing the mess. >>>>>>>>>> >>>>>>>>>> Oh, and generators? I don't fully understand these things. Do >>>>>>>>>> they work with promises? Can you use a generator to process a >>>>>>>>>> stream? How >>>>>>>>>> do generators work with or compare to async/await? Who knows... >>>>>>>>>> >>>>>>>>>> I think it's safe to say that asynchrony is a confusing mess. *But >>>>>>>>>> it shouldn't be. *The concept of "do it now" or "do it later" >>>>>>>>>> is as easy as 123. >>>>>>>>>> >>>>>>>>>> Recently, I read through Jake Archibald's JavaScript Promises: >>>>>>>>>> an Introduction >>>>>>>>>> <https://developers.google.com/web/fundamentals/primers/promises>. >>>>>>>>>> I really enjoy Jake Archibald's writing. He makes JavaScript less >>>>>>>>>> boring. >>>>>>>>>> But wow, understanding promises in their full depth is really >>>>>>>>>> complicated. >>>>>>>>>> Sure, a simple promise is more or less a callback, easy peasy. But >>>>>>>>>> once >>>>>>>>>> you start composing parallel and series tasks, add error handling, >>>>>>>>>> and try >>>>>>>>>> to understand the control flow - it's a lot. >>>>>>>>>> >>>>>>>>>> I feel like Promises could automatically *render a diagram *when >>>>>>>>>> using them. In Jake's very practical example (request a list of >>>>>>>>>> chapters, >>>>>>>>>> load all chapters in parallel, then append them to the page in order) >>>>>>>>>> there's a lot going on, to say the least. Wouldn't it be nice to >>>>>>>>>> see a >>>>>>>>>> diagram of these tasks? A timeline maybe? >>>>>>>>>> >>>>>>>>>> Imagine debugging a complex sequence of async actions. And you >>>>>>>>>> have no idea which piece is failing. Using the console to log >>>>>>>>>> values, and >>>>>>>>>> trying to step through the code with the debugger are two of your >>>>>>>>>> basic >>>>>>>>>> approaches. But honestly, neither of these really *show *you >>>>>>>>>> what's going on. >>>>>>>>>> >>>>>>>>>> Chrome Dev Tools has an awesome timeline GUI. I've spent an hour >>>>>>>>>> here or there tinkering with it, but can't make sense of a lot of it. >>>>>>>>>> There are 100's if not 1000's of very generic blocks that show up on >>>>>>>>>> the >>>>>>>>>> timeline, that don't clearly identify what they are. And I don't >>>>>>>>>> believe >>>>>>>>>> there's any way to visualize promises on this timeline. >>>>>>>>>> >>>>>>>>>> *The problem with Promises* >>>>>>>>>> I want to create a file system framework for node. I'd like to >>>>>>>>>> make watching the files for changes a default feature. The problem >>>>>>>>>> with >>>>>>>>>> promises, is that you can't re-resolve them. >>>>>>>>>> >>>>>>>>>> So I'm basically left with streams, or plain old callbacks. Or >>>>>>>>>> trying to recreate the promises every time they resolve... >>>>>>>>>> >>>>>>>>>> What's the end game? 100 years from now? >>>>>>>>>> >>>>>>>>>> Frankly, this is the most important question. I feel like if we >>>>>>>>>> take a step back, and try to solve these problems for the long term, >>>>>>>>>> we'd >>>>>>>>>> be better off. >>>>>>>>>> >>>>>>>>>> And so, it's 5:15. Well done, Michael. Well done. >>>>>>>>>> >>>>>>>>>> *The Future* >>>>>>>>>> If anyone has made it this far, I'm going to tell you a quick >>>>>>>>>> summary of my plan: >>>>>>>>>> >>>>>>>>>>1. make an ultra-simple web framework (almost done?) >>>>>>>>>>2. use that framework to make a CMS to kill WordPress >>>>>>>>>>3. turn that CMS into a web OS that does everything a real OS >>>>>>>>>>can do, only better >>>>>>>>>>4. turn that web OS into a real, bare metal OS >>>>>>>>>>5. make lots of amazing (useful) software (like photoshop, >>>>>>>>>>blender, after effects, CAD, etc) >>>>>>>>>> >>>>>>>>>> Software development is sluggish. Most software is painful to >>>>>>>>>> use. Windows, Photoshop/Illustrator, many websites... Open source >>>>>>>>>> software doesn't get the funding/momentum it needs to really kill >>>>>>>>>> these >>>>>>>>>> proprietary alternatives. We need to change that. I'm going to >>>>>>>>>> change >>>>>>>>>> that. >>>>>>>>>> >>>>>>>>>> Stay tuned. >>>>>>>>>> >>>>>>>>>> ___ >>>>>>>>>> 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 > > -- Jeremy Martin 661.312.3853 @jmar777 <https://twitter.com/jmar777> / @j <https://stream.live/j> ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Make comma at the end of line optional
*> What am I missing?*
Nothing with respect to function arguments, AFAICT.
But to beat the dead-cognitive-overhead horse again, the rules around ACI
(Automatic Comma Insertion) appear to require too many exceptions. We've
already covered:
- ACI doesn't apply at all between variable declarations
- ACI has exceptions around getter/setter properties in object literals.
I hadn't thought of these before, but there's also:
- ACI would need exceptions in object and array literals following yield
in generator functions.
- ACI would need exceptions in object and array literals following await
in async functions.
I would wager this isn't an exhaustive list yet, either.
To be clear, these aren't exceptions in the grammar itself (the ASI-style
"insert comma if next token would generate a syntax error" is sufficient to
handle all of these cases), but they *are* exceptions that developers and
tooling would need to hold onto, and IMHO, relegate the purported
readability improvements.
On Wed, Sep 13, 2017 at 1:55 PM, Naveen Chawla <naveen.c...@gmail.com>
wrote:
> `x` `[y]` would be invalid syntax, right?
> So
> ```js
> x
> [y]
> ```
> would automatically insert a comma in the case of a function call
> arguments list, right?
>
> That's exactly what would be desired. What am I missing?
>
> On Wed, 13 Sep 2017 at 20:52 Boris Zbarsky <bzbar...@mit.edu> wrote:
>
>> On 9/13/17 9:57 AM, Naveen Chawla wrote:
>> > By this behaviour (a modification to the initial "complete statement
>> > produces comma" version of this proposal), everything would work
>> > perfectly, no?
>>
>> If by "perfectly" you mean "have hard-to-predict somewhat nonlocal
>> behavior that makes any code relying on this a hard-to-read footgun",
>> then the answer might be "yes". For pretty much any other definition of
>> "perfectly", I'm fairly sure the answer is "no".
>>
>> > Great to hear those counter-examples as I don't know enough about ASI,
>>
>> Still in the context of ASI, here are some examples of why ASI is a bad
>> idea:
>>
>> 1) What does this return?
>>
>>function f() {
>> return
>> 5;
>>}
>>
>> 2) What does this alert?
>>
>>var str = "hello";
>>var x = str
>>[x].forEach(() => alert(x))
>>
>> Now back to automatic comma insertion... In your example:
>>
>>function doStuff(
>>x
>>y
>>z
>>){
>>}
>>
>> if someone changes doStuff to take an array as the second arg and you
>> modify the call as:
>>
>>function doStuff(
>>x
>>[y]
>>z
>>){
>>}
>>
>> suddenly you need to insert a comma after the "x" to preserve the right
>> semantics, no? This is not terribly intuitive or obvious. It gets even
>> worse in a situation like this:
>>
>>function doStuff(
>>x
>>/* The next argument is an array for good reasons that we
>> will now expound on in a long comment, etc, etc */
>>[y]
>>){
>>}
>>
>> Quick, tell me without testing this or looking at the spec for a while
>> whether this is a valid call to doStuff, with one argument, or a syntax
>> error that would trigger comma insertion.
>>
>> But more generally, if you just use your favorite search engine on the
>> phrase "automatic semicolon insertion", you will get a slew of articles
>> explaining the pitfalls.
>>
>> -Boris
>>
>
> ___
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
>
--
Jeremy Martin
661.312.3853
@jmar777 <https://twitter.com/jmar777> / @j <https://stream.live/j>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Make comma at the end of line optional
Quick side note regarding multiple variable declarations: both versions of
this proposal (OP's newline-based proposal and the ASI-inspired version)
result in code breakage:
```
const
x = 5
y = 6
z = 7
```
Under existing ASI rules, this is currently equivalent to:
```
const x = 5;
// y and z are global
y = 6;
z = 7;
```
If we use newline based comma insertion (or give ASI-style comma insertion
precedence over semicolon insertion), then this proposal would result in
the following equivalent:
```
const
x = 5,
// y and z are now lexically scoped constants
y = 6,
z = 7;
```
Unless I'm missing something, both of those scenarios definitely preclude
multiple variable declarations from this proposal.
That being said, the ASI-inspired semantics seems like it could have more
legs in other contexts, although I would personally argue that too little
is offered in exchange for the cognitive overhead of a new rule with
ASI-style exceptions attached to it (i.e.., "comma before newlines, except
after get, and set, variable declarations, ...").
On Wed, Sep 13, 2017 at 9:57 AM, Naveen Chawla <naveen.c...@gmail.com>
wrote:
> I'm not really familiar with ASI but they key factor mentioned in this
> discussion is this (by Claude Pache):
>
> *A implicit semicolon is not added when a declaration would be complete,
> but when the next token would produce a syntax error. *
>
> By this behaviour (a modification to the initial "complete statement
> produces comma" version of this proposal), everything would work perfectly,
> no?
>
> The multi-line get would not produce a comma, and hence the scheme is
> backwards compatible, right?
>
> Please provide a counter-example if I have missed something.
>
> As for the benefit, the time savings in not having to debug accidentally
> omitted commas and not having to add them in the first place are, I think,
> an improvement. And of course those who want to continue using commas
> everywhere, can:
>
> ```js
> function doStuff(
> x
> y
> z
> ){
> }
> ```
>
> ```
> const
>x = 5
>y = 6
>z = 7
> ```
>
> Great to hear those counter-examples as I don't know enough about ASI, and
> the related subject, to picture the pitfalls (sorry for my ignorance on
> this). Also it would be good for reference on this proposal...
>
> On Wed, 13 Sep 2017 at 18:40 Boris Zbarsky <bzbar...@mit.edu> wrote:
>
>> On 9/13/17 9:05 AM, Naveen Chawla wrote:
>> > Can someone remind me of the problem doing it this way, if any?
>>
>> You mean apart from all the existing footguns ASI has?
>>
>> -Boris
>> ___
>> 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
>
>
--
Jeremy Martin
661.312.3853
@jmar777 <https://twitter.com/jmar777> / @j <https://stream.live/j>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Re: Make comma at the end of line optional
*> Can someone remind me of the problem doing it this way, if any? (I'm not
sure it has been mentioned yet)*
The problem is in how this proposal has currently been structured:
*> [...] if line is a complete statement and next line is not an operator
than consider it as complete argument (field, element) declaration.*
In the provided example...
```js
{
get
x() //valid syntax after "get", so no comma inserted
}
```
... the `get` line is a valid, complete shorthand property declaration, so
a comma would be inserted, and thus changing the semantics of already valid
code.
As is the case with virtually all potential syntax ambiguities, this can be
worked around through exceptions and extra rules regarding when commas
are/aren't inserted, but that tends this proposal towards the same
idiosyncratic footguns that come with ASI.
This is obviously a subjective analysis, but this proposal seems to
introduce too much wtfjs material in exchange for too little in
time/character savings.
On Wed, Sep 13, 2017 at 9:05 AM, Naveen Chawla <naveen.c...@gmail.com>
wrote:
> Very interesting point. Is there another way to get this optional comma
> proposal through while being backwards compatible? I really like the idea.
>
> If it worked like ASI, then surely it would allow the multi-line `get`
> case?:
>
> ```js
> {
> get
> x() //valid syntax after "get", so no comma inserted
> }
> ```
>
> Can someone remind me of the problem doing it this way, if any? (I'm not
> sure it has been mentioned yet)
>
>
>
> On Wed, 13 Sep 2017 at 18:11 Isiah Meadows <isiahmead...@gmail.com> wrote:
>
>> I can assure you that will likely never happen, because it's a pretty
>> obvious identifier to use in more generic or high-context scenarios.
>> (Think: `get(foo, bar)`, and I've done that plenty of times.)
>>
>> On Wed, Sep 13, 2017, 03:05 Naveen Chawla <naveen.c...@gmail.com> wrote:
>>
>>> Can't `get` be relegated to a reserved/keyword, like `let`, `yield` and
>>> `await` were? Just curious about that kind of process & decision?...
>>>
>>> On Wed, 13 Sep 2017 at 05:25 Matthew Robb <matthewwr...@gmail.com>
>>> wrote:
>>>
>>>> Okay what would be the cons to allowing semi colons in place of commas
>>>> in object literals?
>>>>
>>>> I have an aversion to dangling commas. They're like,
>>>>
>>>> On Sep 12, 2017 7:40 PM, "Jordan Harband" <ljh...@gmail.com> wrote:
>>>>
>>>>> I would take commas over a mixture a thousand times over; I'd do the
>>>>> same with semicolons - it's not the presence or absence of these tokens
>>>>> that causes a problem, it's the ambiguity.
>>>>>
>>>>> Introducing the same horrific ambiguity around semicolons, for commas,
>>>>> does not sound like a good idea.
>>>>>
>>>>> On Tue, Sep 12, 2017 at 1:57 PM, Tab Atkins Jr. <jackalm...@gmail.com>
>>>>> wrote:
>>>>>
>>>>>> On Tue, Sep 12, 2017 at 1:49 PM, Алексей <aga...@gmail.com> wrote:
>>>>>> > Think of it from a different way: if there would be no ',' how
>>>>>> would you
>>>>>> > react on the idea of adding it? Peaty sour every one would decide
>>>>>> that would
>>>>>> > be a complete nonsense.
>>>>>>
>>>>>> This sort of hypothetical isn't useful; you're not proposing switching
>>>>>> over to *solely* comma-less, you're proposing a *mixture* of comma and
>>>>>> comma-less being allowed. That has very different ergonomics than
>>>>>> either all-comma or all-comma-less.
>>>>>>
>>>>>> The hypothetical comma-less language would also have made many
>>>>>> different syntax decisions over the years to accommodate that, which
>>>>>> current JS has *not* made. This causes the sorts of problems that
>>>>>> Claude/etc have pointed out.
>>>>>>
>>>>>> ~TJ
>>>>>> _______
>>>>>> 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
>>>
>>
> ___
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
>
--
Jeremy Martin
661.312.3853
@jmar777 <https://twitter.com/jmar777> / @j <https://stream.live/j>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Make comma at the end of line optional
Apologies, I was butchering the property getter syntax. With the correct
syntax, the backwards compatibility concern remains, however:
const get = "foo";
const obj = {
get
y() { return 2 }
};
console.log(obj.get);
// current: `undefined`
// under this proposal: `"foo"`
You can try it yourself here: https://es6console.com/j7hy49k4/
On Tue, Sep 12, 2017 at 2:36 PM, Алексей <aga...@gmail.com> wrote:
> Am... no. Right now this example would just not work. For now this code is
> invalid.
>
> 2017-09-12 21:33 GMT+03:00 Jeremy Martin <jmar...@gmail.com>:
>
>> *> The reason why we have a discussions about whether to rely on ASI or
>> insert them manually is because ASI has problems (return is one of them). *
>>
>> This seems to come from the perspective that ASI was a poorly specified
>> feature, as opposed to a recovery mechanism for poorly terminated
>> statements.
>>
>> That being said, even with ASI completely removed from the discussion,
>> your proposal has some significant barriers to overcome -- most notably the
>> lack of backwards compatibility.
>>
>> Examples have already been provided where your proposal would change the
>> semantics of *already *valid code. E.g.,
>>
>> const get = "foo";
>>
>> const obj = {
>> get
>> y: 2
>> };
>>
>> console.log(obj.get);
>> // under current rules: `undefined`
>> // under your new proposal: `"foo"`
>>
>> If you introduce new rules to resolve that ambiguity or to preserve
>> backwards compatibility, you've now created a situation similar to ASI,
>> where developers have to remember a list of exceptions before they elide a
>> comma.
>>
>> Even in the absence of backwards compatibility concerns, you need to
>> provide a persuasive argument that the cost-benefit ratio justifies the
>> effort, and judging from initial feedback, I think that will be an uphill
>> battle.
>>
>> On Tue, Sep 12, 2017 at 2:12 PM, Алексей <aga...@gmail.com> wrote:
>>
>>> The reason why we have a discussions about whether to rely on ASI or
>>> insert them manually is because ASI has problems (return is one of them).
>>> And they can't be fixed because fixes are not backward compatible. Based on
>>> this experience it would be possible to determine the rules that would not
>>> have that gaps or their kind.
>>>
>>> 2017-09-12 20:32 GMT+03:00 Claude Pache <claude.pa...@gmail.com>:
>>>
>>>>
>>>> > Le 12 sept. 2017 à 18:57, Алексей <aga...@gmail.com> a écrit :
>>>> >
>>>> > Don't you think that line break is a strong punctuation by itself?
>>>>
>>>> It could have been. Unfortunately, in JS, it is not.
>>>>
>>>> Automatic semi-colon insertion (ASI) could be seen as an attempt to
>>>> have their cake and eat it too. Or, as a compromise between the two options
>>>> by making *some* line breaks significant (e.g., the one after `return`).
>>>>
>>>> But in general, line breaks are not significant enough to allow to
>>>> introduce ASI-like rules after the fact, that would work reliably enough.
>>>>
>>>> BTW, the title of the thread, “Make comma at the end of line optional”,
>>>> reveals a probable misunderstanding of the feature. In JS, semicolons are
>>>> not “optional”, they are “automatically inserted”. That makes a difference
>>>> when parsing:
>>>>
>>>> ```js
>>>> a = b
>>>> +c
>>>> ```
>>>>
>>>>
>>>> —Claude
>>>>
>>>>
>>>
>>> ___
>>> es-discuss mailing list
>>> es-discuss@mozilla.org
>>> https://mail.mozilla.org/listinfo/es-discuss
>>>
>>>
>>
>>
>> --
>> Jeremy Martin
>> 661.312.3853 <(661)%20312-3853>
>> @jmar777 <https://twitter.com/jmar777> / @j <https://stream.live/j>
>>
>>
>
--
Jeremy Martin
661.312.3853
@jmar777 <https://twitter.com/jmar777> / @j <https://stream.live/j>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Make comma at the end of line optional
*> The reason why we have a discussions about whether to rely on ASI or
insert them manually is because ASI has problems (return is one of them). *
This seems to come from the perspective that ASI was a poorly specified
feature, as opposed to a recovery mechanism for poorly terminated
statements.
That being said, even with ASI completely removed from the discussion, your
proposal has some significant barriers to overcome -- most notably the lack
of backwards compatibility.
Examples have already been provided where your proposal would change the
semantics of *already *valid code. E.g.,
const get = "foo";
const obj = {
get
y: 2
};
console.log(obj.get);
// under current rules: `undefined`
// under your new proposal: `"foo"`
If you introduce new rules to resolve that ambiguity or to preserve
backwards compatibility, you've now created a situation similar to ASI,
where developers have to remember a list of exceptions before they elide a
comma.
Even in the absence of backwards compatibility concerns, you need to
provide a persuasive argument that the cost-benefit ratio justifies the
effort, and judging from initial feedback, I think that will be an uphill
battle.
On Tue, Sep 12, 2017 at 2:12 PM, Алексей <aga...@gmail.com> wrote:
> The reason why we have a discussions about whether to rely on ASI or
> insert them manually is because ASI has problems (return is one of them).
> And they can't be fixed because fixes are not backward compatible. Based on
> this experience it would be possible to determine the rules that would not
> have that gaps or their kind.
>
> 2017-09-12 20:32 GMT+03:00 Claude Pache <claude.pa...@gmail.com>:
>
>>
>> > Le 12 sept. 2017 à 18:57, Алексей <aga...@gmail.com> a écrit :
>> >
>> > Don't you think that line break is a strong punctuation by itself?
>>
>> It could have been. Unfortunately, in JS, it is not.
>>
>> Automatic semi-colon insertion (ASI) could be seen as an attempt to have
>> their cake and eat it too. Or, as a compromise between the two options by
>> making *some* line breaks significant (e.g., the one after `return`).
>>
>> But in general, line breaks are not significant enough to allow to
>> introduce ASI-like rules after the fact, that would work reliably enough.
>>
>> BTW, the title of the thread, “Make comma at the end of line optional”,
>> reveals a probable misunderstanding of the feature. In JS, semicolons are
>> not “optional”, they are “automatically inserted”. That makes a difference
>> when parsing:
>>
>> ```js
>> a = b
>> +c
>> ```
>>
>>
>> —Claude
>>
>>
>
> ___
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
>
--
Jeremy Martin
661.312.3853
@jmar777 <https://twitter.com/jmar777> / @j <https://stream.live/j>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Make comma at the end of line optional
const object = {
get // not a complete declaration statement - so no implicit comma here
y: 2 // continuation of a previous line
}
The `get` declaration actually *is* a valid declaration (see shorthand
property names here:
https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Operators/Object_initializer#New_notations_in_ECMAScript_2015
).
On Tue, Sep 12, 2017 at 12:00 PM, Алексей <aga...@gmail.com> wrote:
> Sorry, but I don't see any problems with example you provide:
>
> const object = {
> get // not a complete declaration statement - so no implicit comma here
> y: 2 // continuation of a previous line
>
> z: x // complete declaration statement and next line is not an operator
> - implicit comma here
> in: "foo"
> }
>
> 2017-09-12 18:53 GMT+03:00 Claude Pache <claude.pa...@gmail.com>:
>
>> There are [no LineTerminator here] rules in the ES grammar, in order to
>> prevent the most pernicious trap when using ASI:
>>
>> ```
>> return // implicit semicolon here
>> a = b
>> ```
>>
>> Those [no LineTerminator here] rules have not been included in constructs
>> that don’t need them. As a result:
>>
>> ```
>> const object = {
>> get // no implicit comma here
>> y: 2
>>
>> z: x // no implicit comma here
>> in: "foo"
>> }
>> ```
>>
>> So, no, it’s not a good idea.
>>
>> —Claude
>>
>>
>
> ___
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
>
--
Jeremy Martin
661.312.3853
@jmar777 <https://twitter.com/jmar777> / @j <https://stream.live/j>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Proposal: Specifying an Index in Array Literals
I just came across a use case where I wanted to create a shallow copy of an
array, while also updating the value at a particular index.
Is it feasible to extend the spread syntax for array literals in a manner
that supports updating values at a given index, similar to how the object
literal syntax supports updating a particular key?
Here's a quick example to illustrate:
const idx = people.findIndex(/* some predicate */);
if (idx >= 0) {
return [
...people,
[idx]: { ...people[idx], /* updates */ }
];
}
I suppose this implies a way to specify indexes in array literals in the
general case, but I can't think of any particularly compelling use cases
w/out the spread operator involved.
Thanks!
--
Jeremy Martin
@jmar777
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Ranges
While slightly more verbose, the previously suggested `...` syntax does
have a superficial consistency with the spread operator. Both perform an
expansion of sorts, which has a subtle elegance to it, IMO.
On Wed, Dec 14, 2016 at 4:02 AM, Hikaru Nakashima <oao.hikaru@gmail.com>
wrote:
> I understand.
> I hope to find a good form of literals.
>
> Is there a fact that literals are easier to optimize in the following
> cases?
>
> ```
> for (let i of [1 to 5]) { .. }
> vs
> for (let i of Array.range(1, 5)) { .. }
> ```
>
> If so, it seems that we can attract vendors' interests.
>
> 2016-12-14 17:29 GMT+09:00 Andy Earnshaw <andyearns...@gmail.com>:
>
>> I think you'd be lucky to even get to that stage. Vendors aren't keen on
>> any kind of backwards incompatibility in new specs and trying to get this
>> to stage 4 with such a glaring one would be practically impossible.
>>
>> It's not just the incompatibility either. You also introduce an
>> inconsistencies where things like `[1..toFixed(2)]` doesn't mean the same
>> as `[ 1..toFixed(2) ]`. That kind of thing is just confusing to developers.
>>
>> When you consider these things, it becomes clear that it's not practical
>> to change the language this way for such a small benefit.
>>
>> On Wed, 14 Dec 2016, 03:00 Hikaru Nakashima, <oao.hikaru@gmail.com>
>> wrote:
>>
>>> Oh, I understood it.
>>> It looks like serious problem, but it is may not actually.
>>> If this spec change doesn't break web, we can introduce this idea?
>>> ___
>>> 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
>
>
--
Jeremy Martin
661.312.3853
http://devsmash.com
@jmar777
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Scheduling of async functions
When mixing callback logic with async functions, it's up to the programmer
to choose the callback semantics that they want.
Forcing execution of the async function into a future task prohibits logic
that requires immediate invocation of a callback, whereas the existing
semantics allow for both immediate and future invocation. At any rate, I
assume this ship has sailed. This is a pretty foundational change to make
in a Stage 4 proposal.
On Tue, Nov 29, 2016 at 11:15 AM, Paolo Amadini <paolo.02@amadzone.org>
wrote:
> As I understand it, as currently specified, the first part of an async
> function, before the first await statement, is executed synchronously.
>
> This is subject to subtle bugs when used with callbacks, which may be
> common with DOM event handlers. Take the following code example:
>
> ```js
> let someCondition = false;
>
> async function onClick(event) {
> if (someCondition) {
> await Promise.resolve(); // Or any other async function.
> }
> event.stopPropagation();
> }
>
> let called = false;
> onClick({ stopPropagation: () => called = true }).catch(console.error);
> console.log("Called:", called);
> ```
>
> The callback is called synchronously or not based on someCondition.
>
> The behavior would be more consistent if the first part of the function
> was scheduled at the next microtask, in other words it would be like
> having an implicit `await Promise.resolve();` at the beginning of every
> async function.
>
> This would not allow async functions to invoke callbacks for DOM events
> at all, without wrapping them in a normal function. Using an async
> function as an event handler directly wouldn't be a good practice
> anyways, because if the async function throws an exception it would
> lead to an unhandled rejection, as if the `.catch()` in the example above
> was missing.
>
> Is the current scheduling a deliberate choice?
>
> I'm asking because async functions have just been implemented in the
> Mozilla JS engine, and it would be good to know that this is what we
> want before async functions get widespread use in our codebase.
>
> Cheers,
> Paolo
> _______
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
--
Jeremy Martin
661.312.3853
http://devsmash.com
@jmar777
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Proposal: anaphoric if and while syntax
> If yes ... why would anyone write that ?
I think it would have to be "yes" (and that's probably just a contrived
example that doesn't demonstrate the usefulness).
Slightly less contrived, I could see the value in this, though. E.g.,
```
router.get('/user', (req, res, next) => {
if (let user = req.session.user) {
// do stuff with user here
} else {
res.status(401).end();
}
});
```
I don't think it works as cleanly with `var`, but `const` and `let` has
some nice precedence with for-statements.
On Thu, Sep 15, 2016 at 2:45 PM, Andrea Giammarchi <
andrea.giammar...@gmail.com> wrote:
> > if( let a = ( let b = 10 ) * 3 > 10 )
>
> I've honestly no idea, at first/quick read, what the hell that would
> produce.
>
> Is `a` going to be just `true` ? 'cause if not, this proposal violates
> operator precedence.
>
> If yes ... why would anyone write that ?
>
> On Thu, Sep 15, 2016 at 7:30 PM, J Decker <d3c...@gmail.com> wrote:
>
>> Why not more generally - allow let/var declarations in expressions?
>>
>> coming from a long and rich C background, I have no issues with the
>> existing mechanisms... but for those languages that do support variable
>> declarations in for loops; I've always wondered why not any expression?
>>
>> if( let a = ( let b = 10 ) * 3 > 10 )
>> ... or ...
>>
>> c = (let a = b*d)
>>
>> granted, the scope is extremely limited in the last case...
>>
>> ___
>> 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
>
>
--
Jeremy Martin
661.312.3853
http://devsmash.com
@jmar777
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Negative indexes
A similar proposal was recently brought up - please check out https://esdiscuss.org/topic/javascript-language-feature-idea to browse the existing conversation on it. On Mon, Feb 1, 2016 at 2:35 PM, Lich <6po...@gmail.com> wrote: > Hi! It would be great if we could use negative indexes, -1 being the index > of the last element of an Array or of an Array-like object . Also, an alias > for console.log would be more than welcome. > > ___ > es-discuss mailing list > es-discuss@mozilla.org > https://mail.mozilla.org/listinfo/es-discuss > > -- Jeremy Martin 661.312.3853 http://devsmash.com @jmar777 ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Javascript Language feature Idea
Don't forget that Array#slice() can accept negative indexes. E.g.: > ['a', 'b', 'c', 'd'].slice(-1) [ 'd' ] Which is nearly as terse as any Array.prototype addition would be, and I think it's at least expressive enough to alleviate the need for one. On Fri, Jan 22, 2016 at 12:59 PM, Sander Deryckere <sander...@gmail.com> wrote: > Since Array inherits from Object, it can have any key, including the key > "-1". So something like list[-1] would break compatibility as users can now > already assign values to the index -1. > > If you want a short way to access the last element, it should probably be > a function in the Array prototype. Something like list.last(). > > Regards, > Sander > > 2016-01-22 18:53 GMT+01:00 RacerD123 <racerd...@gmail.com>: > >> In other programming languages such as python, you can specify the last >> element of a list with "list[-1]" but in javascript you have to do >> "list[list.length-1]". Is there maybe a way to make this feature in >> javascript? >> >> ___ >> 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 > > -- Jeremy Martin 661.312.3853 http://devsmash.com @jmar777 ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Computed Property Name Shorthand Proposal
I'm usually lousy at interpreting the spec (yet here I go!), but I think
the behavior is explained here [1]:
PropertyDefinition[Yield] :
IdentifierReference[?Yield]
CoverInitializedName[?Yield]
PropertyName[?Yield] : AssignmentExpression[In, ?Yield]
MethodDefinition[?Yield]
PropertyName[Yield,GeneratorParameter] :
LiteralPropertyName
[+GeneratorParameter] ComputedPropertyName
[~GeneratorParameter] ComputedPropertyName[?Yield]
LiteralPropertyName :
IdentifierName
StringLiteral
NumericLiteral
ComputedPropertyName[Yield] :
[ AssignmentExpression[In, ?Yield] ]
There are aspects to that grammar that I don't fully grok yet, but your `{
[foo] }` example appears to be trying to combine the `IdentifierReference`
form (which *doesn't support* an `AssignmentExpression`) and the `PropertyName:
AssignmentExpression` form (which *requires* the `AssignmentExpression`).
In other words, all paths in that grammar that lead to a `
ComputedPropertyName` being valid also require the right-hand `
AssignmentExpression`.
[1]
http://people.mozilla.org/~jorendorff/es6-draft.html#sec-object-initializer
On Thu, Aug 27, 2015 at 12:25 PM, Kevin Smith zenpars...@gmail.com wrote:
I'd expect the following to work, given that the prop expression evaluates
to 'bar', and bar is in context.
var foo = 'bar'
var bar = 'ponyfoo'
var baz = { [foo] }
console.log(baz)
// - { bar: 'ponyfoo' }
Hmmm... I'm not sure I would expect any such thing. It seems like you're
proposing some kind of dynamic eval-ish variable binding lookup, which is
probably going to be a no-go.
Kevin
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
--
Jeremy Martin
661.312.3853
http://devsmash.com
@jmar777
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: About generators
Hey (author of suspend here): this post was an earlier attempt I had an explaining some of the concepts involved: http://devsmash.com/blog/whats-the-big-deal-with-generators It covers some of the basics, like, what iterators are, how generators relate to iterators, how generators enable suspended execution within the context of run-to-completion semantics; etc. Hope it helps! On Thu, May 14, 2015 at 10:47 AM, Jason Orendorff jason.orendo...@gmail.com wrote: On Thu, May 14, 2015 at 2:05 AM, mohan.radhakrish...@cognizant.com wrote: Thanks. What is the underlying concurrency framework when we use generators for concurrent workloads ? Does it depend on the particular VM ? Generators aren't for concurrency. When a generator runs, it runs in the same thread as the caller. The order of execution is sequential and deterministic, and never concurrent. Unlike system threads, a generator is only ever suspended at points marked by yield in its body. (copied from https://hacks.mozilla.org/2015/05/es6-in-depth-generators/) -j ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss -- Jeremy Martin 661.312.3853 http://devsmash.com @jmar777 ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Array comprehensions with Spread operator
Thanks, I gathered so after your response. This is why 99% of the time I wait for at least one other person to reply first, and why I *should* wait the remaining 1%... :) On Wed, Apr 15, 2015 at 12:34 PM, Tab Atkins Jr. jackalm...@gmail.com wrote: On Wed, Apr 15, 2015 at 9:31 AM, Jeremy Martin jmar...@gmail.com wrote: Why not just `[...x, ...y]`? Obviously that's a solution to the trivial example that monolithed provided, but it's not a solution to the more general problem he's alluding to, where you're doing a comprehension and want to insert two or more elements into the result in a single iteration. ~TJ -- Jeremy Martin 661.312.3853 http://devsmash.com @jmar777 ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Array comprehensions with Spread operator
Why not just `[...x, ...y]`? On Wed, Apr 15, 2015 at 12:23 PM, monolithed monolit...@gmail.com wrote: ```js let x = [0, 1, 2]; let y = [3, 4, 5]; // Expected [ for (i of [x, y]) ...i ]; // Reality Array.prototype.concat(...[ for (x of [x, y]) i ]); // Result [0, 1, 2, 3, 4, 5] ``` Is there any discussion on this subject? ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss -- Jeremy Martin 661.312.3853 http://devsmash.com @jmar777 ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: classes and enumerability
\o/ On Thu, Jan 29, 2015 at 2:55 PM, Brendan Eich bren...@mozilla.org wrote: Announcement: ES6 class method syntax makes a non-enumerable property of the method's name on the class prototype. That is all. :-) /be Brendan Eich wrote: Herby Vojčík wrote: Personally, I have always believed we are going down the wrong path by switching (from the original max-in class design) to making methods defined within a class definition enumerable. Yes, please, if possible, go back to non-enum methods. I was writing at that time as well, but things ended up enumerable. I even cited a real-world example (Amber objects used in jQuery API as options objects), where enum methods broke the functionality, but non-enum methods allowed things to work. On the agenda for next week, at 4(iii): https://github.com/tc39/agendas/blob/master/2015/01.md /be ___ 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 -- Jeremy Martin 661.312.3853 http://devsmash.com @jmar777 ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Handling error in Promises
Awhile back I did my best to summarize some of the previous es-discuss
threads on a related GitHub thread:
https://github.com/iojs/io.js/issues/11#issuecomment-65971175
Please see the immediately following comment as well for some clarification
on how Bluebird surfaces unhandled rejections.
On Tue, Jan 13, 2015 at 11:27 AM, Jeff Morrison lbljef...@gmail.com wrote:
You might try reading through some of the previous threads that talk
about the trickiness of surfacing promise errors in the general case.
Unfortunately these threads usually devolve into an endless thread of
discussion and debate that become next to impossible to actually read
through later without several hours of spare time and a bottle of
whiskey... But here's a recent one that's not *too* long and kind of talks
about a couple of ideas:
https://esdiscuss.org/topic/async-await-improvements (long, but talks
about a couple potential/proposed solutions)
-Jeff
On 1/13/15 7:44 AM, Marius Gundersen wrote:
A `promise.done()` method that throws if it receives a rejected promise
has been discussed, but the consensus seems to be that browsers instead
should report on rejected unhandled promises that are garbage collected.
This is already implemented in Firefox (at least in the DevTools edition),
where the following code will end up with an error in the console:
```js
var p = new Promise(function(){throw new Error(oh noes);})
p = null;
```
Since there is no way to handle the thrown error outside the promise (the
exception is thrown after the function returns) there isn't any reason for
the exception to travel up the stack. Either the exception must be handled
as a rejected promise or it must be handled in something like
`window.onerror`.
Marius Gundersen
On Tue, Jan 13, 2015 at 12:35 PM, Boopathi Rajaa legend.r...@gmail.com
wrote:
```
Promise
.resolve()
.then(function(){
throw new Error('asdf');
});
```
Bluebird: (errors thrown - Good)
http://jsbin.com/kahuzi/1/edit?html,js,console
native ES6:(errors not thrown)
http://jsbin.com/qivobibowa/3/edit?html,js,console
Shouldn't all Uncaught errors be thrown, instead of catching it inside
the promise only ? For example, If I use Promise within a promise, the
uncaught error in the inner Promise will never be exposed to the outside
world and there is no way to bubble it up to the outside blocks.
`.catch(function(err) { throw err; }) `
will also be caught and nothing would be thrown.
- Boopathi
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
___
es-discuss mailing
listes-discuss@mozilla.orghttps://mail.mozilla.org/listinfo/es-discuss
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
--
Jeremy Martin
661.312.3853
http://devsmash.com
@jmar777
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: classes and enumerability
Props to Rick for bringing some analytical rigor into the discussion. Unfortunately all I can provide in response is more anecdotal and opinion-based, but, nonetheless, here's how I would counter that: First, people are lazy, and programmers are people. Seeing a lot of non-non-enumerable class methods is, IMO, more indicative of the path of least resistance, not an indicator of calculated, intended behavior. Second, to quote Kevin from earlier, If we want to preserve any kind of conceptual integrity for enumerability, then enumerability must indicate that the property is a data element within a data structure. A thousand times, this. Properties are state, methods are behavior; this is just OOP 101 (right?). And I don't see any compelling arguments being made for enumerating the behavior of an object. I hate relying on anecdotes, but for all the times I've used ES5-style classes, I have always ended up creating enumerable methods simply because that's the default behavior. I have never, *ever*, done this as a design decision, and I'd wager (since I have the luxury of no data to prove or disprove this) that that's a majority position. On Wed, Dec 24, 2014 at 4:56 PM, Rick Waldron waldron.r...@gmail.com wrote: On Wed Dec 24 2014 at 4:49:36 PM Kevin Smith zenpars...@gmail.com wrote: Here is the summary: Total Files Read: 11038 Files Containing Explicit 'enumerable: false': 149 Occurrences of 'enumerable: false' (and variants): 206 I love this kind of analysis - thanks! I was actually inspired by a similar report you created for the list in the past. My interpretation of this data is that non-enumerability isn't important enough to bother with in the vast majority of cases. Yes, this was my interpretation as well. It *may* still be that non-enumerability is the least-surprise option for class methods, but certainly users don't care enough about the issue currently to bother with typing in enumerable: false. I'm still concerned about the refactoring hazard argument. I think the idea is that if I change some ES5-style class into an ES6-style class, then I need to have good unit tests already in place to make sure that non-enumerability won't break things. Otherwise, I can't do the refactor. Agreed: this has also been my main argument when the subject has come up in the past. Rick ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss -- Jeremy Martin 661.312.3853 http://devsmash.com @jmar777 ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
RE: classes and enumerability
In all the discussions I've observed, the primary argument for enumerability has been consistency with ES5 prototype conventions. I don't think I've seen a single argument in favor, though, based on the actual intrinsic merits of that behaviour. So, do such arguments exist? On Dec 23, 2014 11:26 PM, Gary Guo nbdd0...@hotmail.com wrote: I would say enumerate through classes' or instances' properties are a strange use and should be discouraged. I would prefer nothing but instance properties to be enumerable. To me, it is illogical for methods to be enumerable. ___ 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: Syntax sugar for single exit and early exit functions.
`validate: { ... }`
Is that an ES7 feature? I don't recognize it from ES6, and can't seem to
find a relevant proposal with that syntax...
On Mon, Nov 17, 2014 at 11:51 AM, Andreas Rossberg rossb...@google.com
wrote:
On 17 November 2014 17:29, Alex Kocharin a...@kocharin.ru wrote:
17.11.2014, 03:07, “Biju” bijumaill...@gmail.com:
I wish, I could write elegant two of the code pattern I use frequently.
[...]
Patten 2.
I do like to code functions with early exit, like
function someValidationProcess(){
doStuff();
if(condition_1()){
doCleanUp_1();
doCleanUp_2();
}
doAnotherStuff();
if(condition_2()){
doCleanUp_1();
doCleanUp_2();
}
doYetAnotherStuff();
if(condition_3()){
doCleanUp_1();
doCleanUp_2();
}
doMoreStuff();
doCleanUp_1();
doCleanUp_2();
}
Sounds like you would like to have monad comprehension syntax. :)
How about a loop?
function someValidationProcess() {
do {
doStuff()
if (condition_1()) break
doAnotherStuff()
if (condition_2()) break
doYetAnotherStuff()
if (condition_3()) break
doMoreStuff()
} while(0)
doCleanUp_1()
doCleanUp_2()
}
No need for a fake loop:
function someValidationProcess() {
validate: {
doStuff()
if (condition_1()) break validate
doOtherStuff()
if (condition_2()) break validate
// etc.
}
doCleanUp_1()
doCleanUp_2()
}
But I'd rather use a separate function for the clean-up.
/Andreas
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
--
Jeremy Martin
661.312.3853
http://devsmash.com
@jmar777
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Proposal: Syntax sugar for single exit and early exit functions.
OH JEEZ. Please ignore previous email.
On Mon, Nov 17, 2014 at 12:00 PM, Jeremy Martin jmar...@gmail.com wrote:
`validate: { ... }`
Is that an ES7 feature? I don't recognize it from ES6, and can't seem to
find a relevant proposal with that syntax...
On Mon, Nov 17, 2014 at 11:51 AM, Andreas Rossberg rossb...@google.com
wrote:
On 17 November 2014 17:29, Alex Kocharin a...@kocharin.ru wrote:
17.11.2014, 03:07, “Biju” bijumaill...@gmail.com:
I wish, I could write elegant two of the code pattern I use frequently.
[...]
Patten 2.
I do like to code functions with early exit, like
function someValidationProcess(){
doStuff();
if(condition_1()){
doCleanUp_1();
doCleanUp_2();
}
doAnotherStuff();
if(condition_2()){
doCleanUp_1();
doCleanUp_2();
}
doYetAnotherStuff();
if(condition_3()){
doCleanUp_1();
doCleanUp_2();
}
doMoreStuff();
doCleanUp_1();
doCleanUp_2();
}
Sounds like you would like to have monad comprehension syntax. :)
How about a loop?
function someValidationProcess() {
do {
doStuff()
if (condition_1()) break
doAnotherStuff()
if (condition_2()) break
doYetAnotherStuff()
if (condition_3()) break
doMoreStuff()
} while(0)
doCleanUp_1()
doCleanUp_2()
}
No need for a fake loop:
function someValidationProcess() {
validate: {
doStuff()
if (condition_1()) break validate
doOtherStuff()
if (condition_2()) break validate
// etc.
}
doCleanUp_1()
doCleanUp_2()
}
But I'd rather use a separate function for the clean-up.
/Andreas
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
--
Jeremy Martin
661.312.3853
http://devsmash.com
@jmar777
--
Jeremy Martin
661.312.3853
http://devsmash.com
@jmar777
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Array.isArray(new Proxy([], {})) should be false (Bug 1096753)
I don't have the data to back this up, but I would argue that the developer community has essentially adopted `Array.isArray()` as a sane replacement for `Object.prototype.toString.call(maybeArray) === '[object Array]'`. I realize this forum doesn't have the luxury of *not* considering the nuances between a value having the right [[Class] property vs. having Array.prototype in the chain vs. having an exotic length property, etc., but I would at least suggest that the consumers of `Array.isArray()` are largely just concerned with whether or not they can do everything with a particular value that they could do if it were an actual array, while maintaining equal code semantics. Allen's previous comments: Proxies are not transparent forwarders! In particular their default handling of the `this` value on method invokes will break any built-in method that needs to access internal slots of an object. ...lead me to believe that this isn't the case for proxified Arrays, so I'd have to reverse my earlier position, as `Array.isArray(proxifiedArray)` evaluating to true just seems likely to break code. On Fri, Nov 14, 2014 at 3:36 PM, Brendan Eich bren...@mozilla.org wrote: Tom Van Cutsem wrote: No really, it was a way to expose a test of the [[Class]] internal property. That test wasn't dependent upon the [[Prototype]] chain. I think what Domenic was saying is that Array.isArray used such a test *because* instanceof Array didn't work reliably cross-realms. I too vaguely recollect that reliable cross-realm instanceof Array testing was a primary motivation for Array.isArray. Yes, that was Crock's stated motivation as I recall. Here's a 2003-era post from Doug: https://groups.google.com/forum/#!msg/comp.lang.javascript/XTWYCOwC96I/ 70rNoQ3L-xoJ /be ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss -- Jeremy Martin 661.312.3853 http://devsmash.com @jmar777 ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Array.isArray(new Proxy([], {})) should be false (Bug 1096753)
(Mostly) transparent forwarding seems to be one of the more compelling and
generally useful characteristics of Proxies. I have to lean heavily on the
deeper knowledge of the group here, but *if* `new Proxy([], {})` otherwise
behaves like a bonafide array when you treat it like one, then it would be
a pity to lose the ability to take advantage of that over `Array.isArray()`
resolving to false. *If* transparent forwarding is an intended feature of
proxied arrays, then I'd argue it's far too common of a test to discount .
But again, I can't answer those ifs. :)
On Fri, Nov 14, 2014 at 4:54 PM, Brendan Eich bren...@mozilla.org wrote:
Tom Van Cutsem wrote:
2014-11-14 21:52 GMT+01:00 Jeremy Martin jmar...@gmail.com mailto:
jmar...@gmail.com:
Allen's previous comments:
Proxies are not transparent forwarders! In particular their
default handling of the `this` value on method invokes will
break any built-in method that needs to access internal
slots of an object.
...lead me to believe that this isn't the case for proxified
Arrays, so I'd have to reverse my earlier position, as
`Array.isArray(proxifiedArray)` evaluating to true just seems
likely to break code.
For the particular case of Arrays though, because Array methods were
carefully specified to be generic (i.e. to also work on non-array objects),
they will work just fine on proxies-for-arrays:
var p = new Proxy([1,2,3] , {} );
var a = p.map(function(x) { return x + 1; });
console.log(a); // [2,3,4]
So, of all the exotic objects in the ES and WebIDL specs, Arrays are
probably one of the few exceptions where a Proxy wrapper *is* transparent
by default.
Right.
There is no all-or-nothing solution. Allen's words applie to exceptions to
the rule. Arrays and well-written proxies for them fit in the rule. Jeremy,
what do you say?
/be
--
Jeremy Martin
661.312.3853
http://devsmash.com
@jmar777
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Array.isArray(new Proxy([], {})) should be false (Bug 1096753)
My opinion is that array testing is fundamental to core JS and is worth the exception. Knowing that Array.isArray() tests fail for proxies, I'd be afraid to ever create a Proxy for an array that I don't control the complete lifecycle of. That seems to critically inhibit the usefulness of Proxies, especially when transparency seems to have been an intended characteristic of them going all the way back to the strawman days. On Wed, Nov 12, 2014 at 2:37 PM, Kevin Smith zenpars...@gmail.com wrote: In general, it appears that SM unwraps proxies so that internal slot access is transparently forwarded. I don't see any such unwrapping in the ES spec though. I assume that the spec is correct? ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss -- Jeremy Martin 661.312.3853 http://devsmash.com @jmar777 ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Map: filter/map and more
Not sure if this is sufficient motivation to accelerate the timeline for
adding suitable parallels from Array.prototype, but it may be worth
recalling what developers did last time there were obvious gaps in what a
native prototype provided. Array#contains, anyone?
On Wed, Oct 1, 2014 at 3:28 PM, Axel Rauschmayer a...@rauschma.de wrote:
Then thing is: if we'd like to use maps for such use-case, it brings us
back to that inconvenient imperative style of assignments (even worse,
since you have to repeat that `.set(...)` constantly):
```
var requestData = new Map();
requestData.set(Names.ID, id);
requestData.set(Names.EMAIL, email);
requestData.set('needsReload', id);
...
```
Note that you can chain:
```js
var requestData = new Map()
.set(Names.ID, id)
.set(Names.EMAIL, email)
.set('needsReload', id);
```
Not too bad, IMO.
--
Dr. Axel Rauschmayer
a...@rauschma.de
rauschma.de
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
--
Jeremy Martin
661.312.3853
http://devsmash.com
@jmar777
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Generators with arrow functions.
This has come up a few times. Check out this thread, for example: http://esdiscuss.org/topic/generator-arrow-functions. On Tue, Sep 23, 2014 at 9:40 AM, Hemanth H.M hemanth...@gmail.com wrote: Is there a mention about it somewhere? Something like: ``` gen = (x) * = yield x+2; ``` I understand that arrow functions are lexically bound and has an explicitly return in it's a one liner. -- *'I am what I am because of who we all are'* h3manth.com http://www.h3manth.com *-- Hemanth HM * ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss -- Jeremy Martin 661.312.3853 http://devsmash.com @jmar777 ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: new instantiation design alternatives
Sorry to interject, but was the rationale for needing a new syntax for this (vs. an API-based solution) presented anywhere? I can't seem to find it. On Fri, Sep 12, 2014 at 10:23 AM, Claude Pache claude.pa...@gmail.com wrote: Le 12 sept. 2014 à 15:19, Kevin Smith zenpars...@gmail.com a écrit : Thanks for this! A question: why is it important to provide this new functionality (new^, this = whatever) to basic constructors? Why not use class syntax as an opt-in to these features? ES classes are only syntax; the objects defined by that syntax are just regular functions. Basically, these functions could have been defined the traditional way and have their properties related to prototypal inheritance manually adjusted afterwards. It would be artificial to limit a feature based on *how* the objects were constructed. —Claude ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss -- Jeremy Martin 661.312.3853 http://devsmash.com @jmar777 ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Strawman: Tuples
Michal - Why have it only throw in strict mode? Tuples would be a new
construct, so no breaking of the web if it throws in all contexts.
Jasper - It's not necessarily a given, but the immutability of tuples
offers some guarantees that are easier to optimize against. E.g., no need
to pre-allocate extra space, as in most array implementations.
On Wed, Sep 10, 2014 at 2:25 PM, Jasper St. Pierre jstpie...@mecheye.net
wrote:
Why would tuples be any more memory efficient than objects or arrays?
On 10 Sep 2014 11:57, Michał Wadas michalwa...@gmail.com wrote:
Should we have new type - tuples?
My proposal:
- Tuples are immutable.
Eg.
var wow = new Tuple('my', 'little', 'Cthulhu');
wow[2] = 'Nyarlathotep'; // throws in strict mode, silently fails in
sloppy mode
- Tuples are primitive type. Comparison between tuples is based on
identity of elements, not identity of tuples
Eg:
new Tuple(Object, Function, null, NaN) === new Tuple(Object, Function,
null, NaN); // true
- typeof new Tuple(); // 'tuple'
- Tuple(['wow', 'a', 'b']) = new Tuple('wow', 'a', 'b'); // true
- Tuple.prototype.add = function add() {
return new Tuple(...this, ...arguments);
}
Pros:
- tuples are very memory efficient
- comparision based on identity of elements is required in many cases
Cons:
- ???
___
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
--
Jeremy Martin
661.312.3853
http://devsmash.com
@jmar777
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Generator return() and exceptions
Now that we have return() it isn't clear to me that we actually need
throw()
Am I understanding correctly that you're suggesting removing throw from
Generator.prototype?
If so, I'd like to suggest that, at a minimum, .throw() has been rather
useful in the context of Node.js control-flow libraries [1] that surface
catchable asynchronous errors.
[1] https://github.com/jmar777/suspend#error-handling
On Wed, Jul 23, 2014 at 1:52 PM, Allen Wirfs-Brock al...@wirfs-brock.com
wrote:
On Jul 23, 2014, at 9:51 AM, Andy Wingo wrote:
On Wed 23 Jul 2014 18:19, Allen Wirfs-Brock al...@wirfs-brock.com
writes:
On Jul 23, 2014, at 1:25 AM, Andy Wingo wrote:
The TC39 notes do not record any discussion of return() causing an
exception to be thrown.
In the latest ES6 draft for-of propagates any exceptions thrown by the
call to return(). See
http://people.mozilla.org/~jorendorff/es6-draft.html#sec-runtime-semantics-
forin-div-ofbodyevaluation step 3.k.ii.1-2
As a matter of design policy we rarely, if ever, just drop exceptions.
I probably didn't explain myself completely; apologies. I meant that
the mechanism of iter.return() should be implemented by throwing an
exception (i.e., as if by iter.throw(new StopIteration)) instead of
returning from the yield point.
Well, in ES6 we don't define iterator termination in terms of a
StopIteration exception.
However, both gen.throw and gen.return are specified in terms of abnormal
completion of a yield:
https://people.mozilla.org/~jorendorff/es6-draft.html#sec-generator.prototype.return
https://people.mozilla.org/~jorendorff/es6-draft.html#sec-generator.prototype.throw
so they both unwind in a similar manner.
consider:
function gen() {
try {
while (true) {
try {yield foo()
} catch (e) {
console.log(throw);
throw (e);
};
}
} finally {
console.log(unwind);
};
}
var g = gen();
g.next();
g.throw(new Error); //logs: throw, unwind
var h = gen();
h.next();
h.return(); //logs: unwind
Now that we have return() it isn't clear to me that we actually need
throw() or whether for-of/yield* should call throw() like they currently do.
This is something I hope to discuss at the upcoming TC39 meeting.
Allen
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
--
Jeremy Martin
661.312.3853
http://devsmash.com
@jmar777
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: TC39 vs the community
I'll make this point as concisely as possible, since this conversation is quite given to noise: While others may disagree, I feel the source of contention/disunity on modules is more fundamental than syntax or who's (not) listening to who. Specifically, ES6 modules are far less immune to platform nuances than other features, like, say, fat-arrows. That is, the merits of fat-arrows are basically the same regardless of what platform you're on... but that isn't (as) true of modules. While there's certainly overlap in what Node vs. Browser vs. PhoneGap (etc.) devs want out of a module loader, there are necessarily divergences as well. I say this hesitantly and with great respect for TC39 and its members... but I have a hard time imagining a unified voice emerging on *anything* that's situated this close to individual, disparate platform needs. On Fri, Jun 20, 2014 at 11:39 AM, John Barton johnjbar...@google.com wrote: On Fri, Jun 20, 2014 at 6:42 AM, Domenic Denicola dome...@domenicdenicola.com wrote: Can you develop these particular accusations? Why would TC39 have priorities that don't align with the needs of developers? especially on modules which are clearly one of the most awaited feature as far as developers are concerned? TC39 has a lot of constituents who use their experience with other languages to develop the shape of features, instead of building on community-developed solutions to the problems the community sees as worth solving. In modules this is particularly apparent. If you want a qualifier for community, try ES5-module using community. The ES5-module using community tried, valiantly, to reach a compromise module solution. They were not successful. Thus ES6 cannot build on their solution. Their experience did however have a huge impact on the ES6 module design. I wouldn't call these accusations, and in general I don't appreciate the uncharitable (perhaps even accusatory) tone of your message. Experience from other languages is valuable in evolving a language---of course! It would be silly to think otherwise. And often these working modes are not in conflict at all, allowing us to solve problems the community has run into by drawing upon our experience with other languages. But there is, especially in this case, a real conflict between the guidance from other languages and the guidance from the ES5-module using community's experience. I started out with a similar opinion. Then I wrote some ES6 code. What we need now is experience from using ES6-modules. We have plenty of decent implementations. We've built nodejs and browser applications based on ES6 modules. That experience shows that the ES6 solution is modestly superior to any ES5 solution. Moreover the ES6 solution interoperates with the main ES5 solutions. Are there projects which attempted to use ES6 modules but where unable to succeed because of technical barriers? Whatever they end up looking and behaving, ES6 modules will happen with the community or without it. They may happen, in that engines may indeed implement the syntax once it settles, and browsers may indeed implement a loader once it's designed and specced. But whether they will be adopted by, say, Node.js (by supplying their own loader implementation), or the 80K packages on npm, or by the developers who are currently using AMD, or the developers who are currently just happy with script tags, is another question. Any claims otherwise are tendentious speculation, to borrow a phrase. Implementors and proponents of legacy systems always fight for their point of view. It's natural and valuable input. But at this point we are speculating about tendencies of developers, not arguing about technical feasibility. Some node developers will never switch; some devs will always use script tags; some business apps will be written in COBOL. It's ok. jjb ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss -- Jeremy Martin 661.312.3853 http://devsmash.com @jmar777 ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: ArrayBuffer neutering
array spec? The length property of an Typed Array is an accessor property. I just updated my working draft of the specification of that accessor ( http://people.mozilla.org/~jorendorff/es6-draft.html#sec-get-%typedarray%.prototype.length not yet updated) and also the accessors for byteLength and byteOffset so they return 0 when the backing ArrayBuffer is observed to be neutered. However, that doesn't directly address the indexed access issues. Implementations presumably want indexed access to typed arrays to be has fast as possible, so they are unlikely to want to make a call to a 'length' accessor property on every indexed access. That's why we specify the [[ArrayLength]] as private state of the the typed array instance. Instead I can either place a IsNeutered guard on the calls to GetValueInBuffer/SetValueInBuffer from the indexed accessors or change GetValueInBuffer/SetValueInBuffer to not throw on neutered buffered accesses. However, this also requires some care to make sure that DataView accesses continue to throw. The bottom line of all of this is we want the fast path for a non-netured typed array access to be as fast as possible while still behaving safely (if not reasonably) in the presence of neuterable ArrayBuffers. What happens if an index which would have been out of range before the object was neutered is passed to the indexed getter or setter? Currently, in the ES spec. it is range checked against the original array length. All out of range accesses return undefined. What happens if the [] operator is used to get or set some random named property against a neutered typed array view? They just work (assuming that the property isn't an integer index). Neutering the backing ArrayBuffer doesn't do anything to the ordinary properties of a typed array instance. Allen ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss -- Jeremy Martin 661.312.3853 http://devsmash.com @jmar777 ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: eval of let, etc. Was: Re: restrictions on let declarations
I rather hate to say it, but I would've actually expected:
4) Given that the eval'd string doesn't create anything typically
considered a block, the let binding would survive past the completion of
the eval in non-strict mode:
(function() {
eval(
var answer=42;
let localToEval = true;
);
console.log(answer); // 42
console.log(localToEval); // true
)();
(function() {
use strict;
eval(
var answer=42;
let localToEval = true;
);
console.log(answer); // ReferenceError: answer is not defined
console.log(localToEval); // ReferenceError: localToEval is not
defined
)();
I'm not necessarily arguing for that behavior, but weighing in since that's
the behavior I would have expected based on existing ES5
strict/non-strict/eval and ES6 let semantics...
On Fri, Feb 14, 2014 at 10:40 AM, Allen Wirfs-Brock
al...@wirfs-brock.comwrote:
On Feb 14, 2014, at 5:49 AM, André Bargull wrote:
How about this?
let x= 0;
if (1) eval(let x= 42; alert(x);); //Is this in its own block?
alert(x);
`eval()` hasn't yet been updated to work with the new lexical declaration
forms, but I hope the example from above will be evaluated in a new block.
See https://bugs.ecmascript.org/show_bug.cgi?id=1788 for a related bug
report.
Goood point and this is something I need to specify in the next couple
weeks so let's look at the alternatives.
First a quick refresher on ES5 era eval.
In ES5, the binding behavior of direct eval differs between strict and
non-strict modes.
In strict mode, each eval instantiates all declarations in a new
environment that is immediately nested within the current
LexicalEnvironment. The scoping behavior is essentially the same as if the
eval code was the body of an iife that occurred at the same place as the
eval call. Bindings introduced by the eval code disappear after completion
of the eval.
In non-strict mode, each eval instantiates all declarations in the current
VariableEnvironment; that is the most immediately enclosing function or
global environment. Bindings introduced by the eval code remain accessible
from that VariableEnvironment after completion of the eval.
For example:
(function() {
use strict;
eval(var answer=42);
console.log(answer); // ReferenceError: answer is not defined
})();
(function() {
eval(var answer=42);
console.log(answer); // 42
})();
For ES6, it makes sense for strict mode evals to behave in this exact same
way. Each eval takes place in its own environment and no bindings survive
the completion of the eval.
For ES6, non-strict evals of code containing only var or function
declarations must have exactly the ES5 behavior in order to maintain
compatibility. But what about eval code that contains new declaration
forms (let/const/class) exclusively or in combination with var/function
declarations? Three possibilities come to mind:
1) Extend the ES5 semantics to include the new declaration forms. For
example:
(function() {
eval(let answer=42);
console.log(answer); // 42
})();
2) Use the strict mode binding semantics if the eval code directly
contains any of the new declaration forms:
(function() {
eval(
var answer=42;
let forceSeprateEnvironment = true;
);
console.log(answer); // ReferenceError: answer is not defined
})();
3) Combination. use ES5 non-strict binding semantics for var/function
declarations but place let/const/class bindings into a per eval environment:
(function() {
eval(
var answer=42;
let localToEval = true;
);
console.log(answer); // 42
console.log(localToEval); // ReferenceError: localToEval is not
defined
)();
It would certainly be possible to specify #1, but I don't like it. Other
than for the global environment it would be cleaner if the new block
scope-able declarations were never dynamically added to the environment.
I think either #2 or #3 is plausible. #2 is a simpler story but
introduces a refactoring hazard. If you have some existing eval code that
defines some global functions or variables, then simply adding a
let/const/class declaration to the eval code ruins those global
declarations.
I prefer the simplicity of #2, but I also worry about the WTF impact it
might have on evolving existing code.
Can we get away with #2, or are we going to have to go with #3? Are there
other alternatives?
Allen
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
--
Jeremy Martin
661.312.3853
http://devsmash.com
@jmar777
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: eval of let, etc. Was: Re: restrictions on let declarations
As far as I can see, your #4 and my #1 are exactly the same. How do you
think they differ?
Actually, on a second read, I don't think they are. I was perhaps more
explicit regarding strict mode, but I think the behavior there was already
clear enough to everyone. :)
On Fri, Feb 14, 2014 at 12:14 PM, Allen Wirfs-Brock
al...@wirfs-brock.comwrote:
As far as I can see, your #4 and my #1 are exactly the same. How do you
think they differ?
Allen
On Feb 14, 2014, at 8:03 AM, Jeremy Martin wrote:
I rather hate to say it, but I would've actually expected:
4) Given that the eval'd string doesn't create anything typically
considered a block, the let binding would survive past the completion of
the eval in non-strict mode:
(function() {
eval(
var answer=42;
let localToEval = true;
);
console.log(answer); // 42
console.log(localToEval); // true
)();
(function() {
use strict;
eval(
var answer=42;
let localToEval = true;
);
console.log(answer); // ReferenceError: answer is not defined
console.log(localToEval); // ReferenceError: localToEval is not
defined
)();
I'm not necessarily arguing for that behavior, but weighing in since
that's the behavior I would have expected based on existing ES5
strict/non-strict/eval and ES6 let semantics...
On Fri, Feb 14, 2014 at 10:40 AM, Allen Wirfs-Brock al...@wirfs-brock.com
wrote:
On Feb 14, 2014, at 5:49 AM, André Bargull wrote:
How about this?
let x= 0;
if (1) eval(let x= 42; alert(x);); //Is this in its own block?
alert(x);
`eval()` hasn't yet been updated to work with the new lexical declaration
forms, but I hope the example from above will be evaluated in a new block.
See https://bugs.ecmascript.org/show_bug.cgi?id=1788 for a related bug
report.
Goood point and this is something I need to specify in the next couple
weeks so let's look at the alternatives.
First a quick refresher on ES5 era eval.
In ES5, the binding behavior of direct eval differs between strict and
non-strict modes.
In strict mode, each eval instantiates all declarations in a new
environment that is immediately nested within the current
LexicalEnvironment. The scoping behavior is essentially the same as if the
eval code was the body of an iife that occurred at the same place as the
eval call. Bindings introduced by the eval code disappear after completion
of the eval.
In non-strict mode, each eval instantiates all declarations in the
current VariableEnvironment; that is the most immediately enclosing
function or global environment. Bindings introduced by the eval code
remain accessible from that VariableEnvironment after completion of the
eval.
For example:
(function() {
use strict;
eval(var answer=42);
console.log(answer); // ReferenceError: answer is not defined
})();
(function() {
eval(var answer=42);
console.log(answer); // 42
})();
For ES6, it makes sense for strict mode evals to behave in this exact
same way. Each eval takes place in its own environment and no bindings
survive the completion of the eval.
For ES6, non-strict evals of code containing only var or function
declarations must have exactly the ES5 behavior in order to maintain
compatibility. But what about eval code that contains new declaration
forms (let/const/class) exclusively or in combination with var/function
declarations? Three possibilities come to mind:
1) Extend the ES5 semantics to include the new declaration forms. For
example:
(function() {
eval(let answer=42);
console.log(answer); // 42
})();
2) Use the strict mode binding semantics if the eval code directly
contains any of the new declaration forms:
(function() {
eval(
var answer=42;
let forceSeprateEnvironment = true;
);
console.log(answer); // ReferenceError: answer is not defined
})();
3) Combination. use ES5 non-strict binding semantics for var/function
declarations but place let/const/class bindings into a per eval environment:
(function() {
eval(
var answer=42;
let localToEval = true;
);
console.log(answer); // 42
console.log(localToEval); // ReferenceError: localToEval is not
defined
)();
It would certainly be possible to specify #1, but I don't like it. Other
than for the global environment it would be cleaner if the new block
scope-able declarations were never dynamically added to the environment.
I think either #2 or #3 is plausible. #2 is a simpler story but
introduces a refactoring hazard. If you have some existing eval code that
defines some global functions or variables, then simply adding a
let/const/class declaration to the eval code ruins those global
declarations.
I prefer the simplicity of #2, but I also
Re: eval of let, etc. Was: Re: restrictions on let declarations
On further reflection, #3 does feel like trying to rewrite the past. For
better or worse, non-strict mode allows declarations to persist past the
eval(). And while strict mode provides a license-to-kill on behavior like
that, I don't really see strong justification for that kind of surprise
factor for let in non-strict mode.
If you're not using strict mode AND you're using eval(), the damage is
arguably already done (or at least the danger already exists). Changing
the behavior of let in this case feels like removing an arbitrary* foot-gun
when we're already in the armory, so to speak.
* Granted it's not completely arbitrary, since `let` is new whereas `var`
is not, but hopefully you get my point...
On Fri, Feb 14, 2014 at 2:23 PM, Erik Arvidsson erik.arvids...@gmail.comwrote:
1 or 3. We have already shot down similiar situations to 2 before. I don't
think it is worth bringing this up again.
1 is the least surprise. It is just bad practice, but so is eval and non
strict mode in the first place.
3 is fine if you think as if there was a block around the whole thing
(except for functions in block in non strict mode).
On Fri Feb 14 2014 at 1:42:13 PM, Jeremy Martin jmar...@gmail.com wrote:
As far as I can see, your #4 and my #1 are exactly the same. How do
you think they differ?
Actually, on a second read, I don't think they are. I was perhaps more
explicit regarding strict mode, but I think the behavior there was already
clear enough to everyone. :)
On Fri, Feb 14, 2014 at 12:14 PM, Allen Wirfs-Brock
al...@wirfs-brock.com wrote:
As far as I can see, your #4 and my #1 are exactly the same. How do you
think they differ?
Allen
On Feb 14, 2014, at 8:03 AM, Jeremy Martin wrote:
I rather hate to say it, but I would've actually expected:
4) Given that the eval'd string doesn't create anything typically
considered a block, the let binding would survive past the completion of
the eval in non-strict mode:
(function() {
eval(
var answer=42;
let localToEval = true;
);
console.log(answer); // 42
console.log(localToEval); // true
)();
(function() {
use strict;
eval(
var answer=42;
let localToEval = true;
);
console.log(answer); // ReferenceError: answer is not defined
console.log(localToEval); // ReferenceError: localToEval is
not defined
)();
I'm not necessarily arguing for that behavior, but weighing in since
that's the behavior I would have expected based on existing ES5
strict/non-strict/eval and ES6 let semantics...
On Fri, Feb 14, 2014 at 10:40 AM, Allen Wirfs-Brock
al...@wirfs-brock.com wrote:
On Feb 14, 2014, at 5:49 AM, André Bargull wrote:
How about this?
let x= 0;
if (1) eval(let x= 42; alert(x);); //Is this in its own block?
alert(x);
`eval()` hasn't yet been updated to work with the new lexical declaration
forms, but I hope the example from above will be evaluated in a new block.
See https://bugs.ecmascript.org/show_bug.cgi?id=1788 for a related bug
report.
Goood point and this is something I need to specify in the next couple
weeks so let's look at the alternatives.
First a quick refresher on ES5 era eval.
In ES5, the binding behavior of direct eval differs between strict and
non-strict modes.
In strict mode, each eval instantiates all declarations in a new
environment that is immediately nested within the current
LexicalEnvironment. The scoping behavior is essentially the same as if the
eval code was the body of an iife that occurred at the same place as the
eval call. Bindings introduced by the eval code disappear after completion
of the eval.
In non-strict mode, each eval instantiates all declarations in the
current VariableEnvironment; that is the most immediately enclosing
function or global environment. Bindings introduced by the eval code
remain accessible from that VariableEnvironment after completion of the
eval.
For example:
(function() {
use strict;
eval(var answer=42);
console.log(answer); // ReferenceError: answer is not defined
})();
(function() {
eval(var answer=42);
console.log(answer); // 42
})();
For ES6, it makes sense for strict mode evals to behave in this exact
same way. Each eval takes place in its own environment and no bindings
survive the completion of the eval.
For ES6, non-strict evals of code containing only var or function
declarations must have exactly the ES5 behavior in order to maintain
compatibility. But what about eval code that contains new declaration
forms (let/const/class) exclusively or in combination with var/function
declarations? Three possibilities come to mind:
1) Extend the ES5 semantics to include the new declaration forms. For
example:
(function() {
eval(let answer=42);
console.log(answer); // 42
Re: Shorthand Function declaration
Seems like this would lead to confusing operator precedence rules as well.
For example:
1foo{}
... is perfectly valid JavaScript today (syntactically, anyway...), and is
equivalent to:
(1 foo) {}
... but I would assume that with the new syntax in place it would really be
interpreted as:
1 function(foo) {}
... which is also valid JavaScript. Not that either of those examples
should ever occur in the real world, but in general I think they indicate
that `` and `` might be better left alone.
On Tue, Feb 11, 2014 at 3:53 PM, Till Schneidereit
t...@tillschneidereit.net wrote:
On Wed, Feb 12, 2014 at 9:39 AM, Tab Atkins Jr. jackalm...@gmail.comwrote:
On Tue, Feb 11, 2014 at 12:33 PM, biscotte a la crevette
biscottealacreve...@gmail.com wrote:
I would like to suggest an alternative function declaration syntax rule
:
http://pastebin.mozilla.org/4258633
That will lead to a way shorter function declaration (like Array [...]
and Object {...} does ) :
long story short : ... will be equivalent to function(...)
Which mean :
var print = name,age{ //eq. to var print = function(name,age){...
console.log(my name is + name + + age + y old.\n);
}
Human = name,age=0{
this.age=age;
this.name=age;
this.toString={
return ...
};
}
And so, will work with anonymous function declaration (which was my
main goal).
my_list.map(val{return val0?-val:val;});//return absolut-ified array
content
Are you aware of the existing arrow functions? Using current ES6,
your example would be written as:
my_list.map(val=val0?-val:val);
Also, there are short method declarations:
var obj = {
foo(bar, baz) {
// stuffs
}
}
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
--
Jeremy Martin
661.312.3853
http://devsmash.com
@jmar777
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Shorthand Function declaration
Forgot to mention, expression-only function bodies would be problematic as
well.
1foobar;
Is that a syntax error?
1 function(foo) { return bar; }
...or does it get interpreted as it would today?
On Tue, Feb 11, 2014 at 4:10 PM, Jeremy Martin jmar...@gmail.com wrote:
Seems like this would lead to confusing operator precedence rules as well.
For example:
1foo{}
... is perfectly valid JavaScript today (syntactically, anyway...), and is
equivalent to:
(1 foo) {}
... but I would assume that with the new syntax in place it would really
be interpreted as:
1 function(foo) {}
... which is also valid JavaScript. Not that either of those examples
should ever occur in the real world, but in general I think they indicate
that `` and `` might be better left alone.
On Tue, Feb 11, 2014 at 3:53 PM, Till Schneidereit
t...@tillschneidereit.net wrote:
On Wed, Feb 12, 2014 at 9:39 AM, Tab Atkins Jr. jackalm...@gmail.comwrote:
On Tue, Feb 11, 2014 at 12:33 PM, biscotte a la crevette
biscottealacreve...@gmail.com wrote:
I would like to suggest an alternative function declaration syntax
rule :
http://pastebin.mozilla.org/4258633
That will lead to a way shorter function declaration (like Array [...]
and Object {...} does ) :
long story short : ... will be equivalent to function(...)
Which mean :
var print = name,age{ //eq. to var print = function(name,age){...
console.log(my name is + name + + age + y old.\n);
}
Human = name,age=0{
this.age=age;
this.name=age;
this.toString={
return ...
};
}
And so, will work with anonymous function declaration (which was my
main goal).
my_list.map(val{return val0?-val:val;});//return absolut-ified
array content
Are you aware of the existing arrow functions? Using current ES6,
your example would be written as:
my_list.map(val=val0?-val:val);
Also, there are short method declarations:
var obj = {
foo(bar, baz) {
// stuffs
}
}
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
--
Jeremy Martin
661.312.3853
http://devsmash.com
@jmar777
--
Jeremy Martin
661.312.3853
http://devsmash.com
@jmar777
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: read only names
This can more or less achieved with getters/setters:
```js
function Obj() {
var x = 'foo';
Object.defineProperty(this, 'x', {
get: function() {
return x;
},
set: function() {
throw new Error('Cannot set property x!');
}
});
}
var obj = new Obj();
console.log(obj.x); // 'foo'
obj.x = 'bar'; // Error!
```
I think ES6 classes will provide some nicer facilities, but I'm not current
on how a public getter / private setter pattern would be achieved outside
of `Object.defineProperty()` at this point.
On Fri, Dec 13, 2013 at 8:34 AM, raul mihaila raul.miha...@gmail.comwrote:
Hello, was there any proposal for object properties that can be read from
anywhere but are writable only from the execution context where the name
associated with the property was defined? Something like:
function Obj() {
ro x; // read only name x
this.x = 2;
this.setX = function (val) {
this.x = val;
};
}
var o = new Obj;
o.x; // 2
o.x = 43; // throws some error
o.x; // 2
o.setX(100);
o.x; // 100
The advantages would be that you are sure that there are no side effects
when the property is accessed and also I'm guessing you have no function
call overhead.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
--
Jeremy Martin
661.312.3853
http://devsmash.com
@jmar777
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Reserving await within Arrow Functions
:) Thanks for clarifying. I guess the part that I'm still questioning, though, is: 1) Arrow functions express mappings This is of course true, but is that not a bit exclusive? They're also great at: 1) Non-mapping iteration (e.g., `forEach()`) 2) Lightweight callbacks 3) Killing off 90% of `var self = this` occurrences. 4) ... not going to continue, speaking to the choir here. If there are grammar or aesthetic issues involved, I can (ahem) yield on that... but I'm struggling with the *conceptual* discriminating between what arrow functions are or aren't for. On Thu, Dec 12, 2013 at 2:25 PM, Kevin Smith zenpars...@gmail.com wrote: I think it's fairly self-evident that they are a natural fit for such use cases, but I find it less self-evident that they are inherently not useful for others (e.g., generators). I feel like I keep seeing the following (implied) argument: 1) Arrow functions are good for mappings 2) Generators aren't mappings 3) Arrow functions aren't good for generators. That would be me. : ) I'm trying to look at things not just in terms of what would be useful, although that's important. I'm looking at the overall design of the language, and understand the way all the parts fit together into a beautiful whole. It's an aesthetic thing, which I can appreciate may be a little difficult to swallow. FWIW, I would restate the argument as follows: 1) Arrow functions express mappings 2) Generators express sequences 3) Don't muddy the waters Anyway, I'm not really trying to convince anyone. I just think we should reserve the right to have this discussion later, and not prematurely commit to =! or whatever. -- Jeremy Martin 661.312.3853 http://devsmash.com @jmar777 ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Try/catch conditional exceptions in light of generators
I can't speak for Benjamin, but I would like to +1 the notion that
try/catches could benefit from some form of error pattern matching. Here's
an example that attempts to avoid conflation with async control-flow
considerations:
```javascript
try {
JSON.parse(getJSONString());
} catch (err) {
if (err instanceof SyntaxError) {
// handle the error
} else {
throw err;
}
}
```
Discriminatory error handling like this is not all that uncommon, and could
potentially benefit from an expansion of the existing guards strawman [1].
For example:
```javascript
try {
JSON.parse(getJSONString());
} catch (err :: SyntaxError) {
// handle the error
}
```
This of course has larger implications, though, as you'd presumably need to
support multiple guarded catches, and behavior for a failed guard is
different in the try/catch scenario than with parameters or properties.
[1] http://wiki.ecmascript.org/doku.php?id=strawman:guards
On Wed, Nov 20, 2013 at 10:24 AM, Brendan Eich bren...@mozilla.com wrote:
Benjamin (Inglor) Gruenbaum wrote:
Hi, thanks for the comment and sorry for the unclarity.
I was refering to my original post in this thread about try/catch with
generators: http://esdiscuss.org/topic/try-catch-conditional-
exceptions-in-light-of-generators#content-0
Yes, but the Domenic pointed out that the reference error there has
nothing to do with generators so much as async control flow in general (it
could be in a function passed as a callback or downward funarg, and called
later by any means). And you seemed to agreed.
It's true that yield allows part of a function to run in a later event
loop turn -- or just in a later iteration of a loop in the same turn.
Generators by themselves are not async in the event loop sense. So first
you need to identify the problem precisely.
If you write
function f() { ... setCallback(function g() {... RefErrHere ... }) ... }
you need test coverage over the body of g.
If you write
function* f() { ... yield; RefErrHere ... }
same deal. There is no difference in kind.
So, is the problem you are citing a general one of test coverage over
async control flow?
/be
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
--
Jeremy Martin
661.312.3853
http://devsmash.com
@jmar777
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Optional Strong Typing
I haven't personally used it, but you may find that TypeScript provides what you're looking for: http://www.typescriptlang.org/ On Fri, Aug 23, 2013 at 1:26 PM, J B por...@gmail.com wrote: Is there any particular reason my JS doesn't support (optional) AS3 style strong typing? All the typing info would be ignored at run-time, but it would be helpful for compile-time checking, code hinting, and general readability of code. Tools like the closure compiler could even strip out all the typing info, and it wouldn't make any difference at run-time. I'm probably beating a dead horse here, but why? ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss -- Jeremy Martin 661.312.3853 http://devsmash.com @jmar777 ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Optional Strong Typing
var foo:String; That's already a compile-time error (as opposed to runtime not sure if that's what you meant by the interpreter throwing an error). On Fri, Aug 23, 2013 at 1:56 PM, J B por...@gmail.com wrote: And just to be clear, I'm not asking for run-time type checking or coercion; I'm simply asking that the interpreter not to thrown an error when it encounters something like this: var foo:String; On Fri, Aug 23, 2013 at 12:45 PM, J B por...@gmail.com wrote: For one, I wouldn't describe strong typing as a pet feature. Two, no, as far as I know, most of those languages in that list don't offer macros or lots of parentheses; and, if they did, then, yeah, maybe it does say something. On Fri, Aug 23, 2013 at 12:41 PM, Domenic Denicola dome...@domenicdenicola.com wrote: In general ECMAScript lacks lots of features. You may well ask why it doesn't have any other pet feature, and you can often point to compile-to-JS languages that add those. This doesn't imply that the feature should be added to the language. Here, let me try: --- I'm aware of LispyScript, as well as all of these: https://github.com/jashkenas/coffee-script/wiki/List-of-languages-that-compile-to-JS . But those languages appear to have been created precisely because ECMAScript lacks features like lots of parentheses or macros. How many of those languages offer lots of parentheses? I count quite a few... Doesn't that say something? --- The existence of a feature in other languages does not imply it should be added to ECMAScript. You'll have to justify better than that why you think strong typing would be valuable to a language that has historically rejected it. (I'll wait for one of the old timers to chime in about the ES4 days here.) ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss -- Jeremy Martin 661.312.3853 http://devsmash.com @jmar777 ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Optional Strong Typing
I mean it's a parse error that will throw prior to attempting to execute
it. For example, consider:
(function() { var foo:String; })
This will throw an error, despite the fact that the function hasn't been
invoked. I replied in haste, though... your point is obviously valid for
other scenarios. Nonetheless, as a non-authoritative response, you're
going to need an argument far more compelling than I can think of to see
static typing seriously considered.
On Fri, Aug 23, 2013 at 2:00 PM, J B por...@gmail.com wrote:
Are you referring to browsers like Chrome that compile the JS first? Then,
yeah, I mean it shouldn't throw an error at compile time.
On Fri, Aug 23, 2013 at 12:59 PM, Jeremy Martin jmar...@gmail.com wrote:
var foo:String;
That's already a compile-time error (as opposed to runtime not sure
if that's what you meant by the interpreter throwing an error).
On Fri, Aug 23, 2013 at 1:56 PM, J B por...@gmail.com wrote:
And just to be clear, I'm not asking for run-time type checking or
coercion; I'm simply asking that the interpreter not to thrown an error
when it encounters something like this: var foo:String;
On Fri, Aug 23, 2013 at 12:45 PM, J B por...@gmail.com wrote:
For one, I wouldn't describe strong typing as a pet feature. Two, no,
as far as I know, most of those languages in that list don't offer macros
or lots of parentheses; and, if they did, then, yeah, maybe it does say
something.
On Fri, Aug 23, 2013 at 12:41 PM, Domenic Denicola
dome...@domenicdenicola.com wrote:
In general ECMAScript lacks lots of features. You may well ask why it
doesn't have any other pet feature, and you can often point to
compile-to-JS languages that add those. This doesn't imply that the
feature
should be added to the language.
Here, let me try:
---
I'm aware of LispyScript, as well as all of these:
https://github.com/jashkenas/coffee-script/wiki/List-of-languages-that-compile-to-JS
.
But those languages appear to have been created precisely because
ECMAScript lacks features like lots of parentheses or macros. How many of
those languages offer lots of parentheses? I count quite a few... Doesn't
that say something?
---
The existence of a feature in other languages does not imply it should
be added to ECMAScript. You'll have to justify better than that why you
think strong typing would be valuable to a language that has historically
rejected it. (I'll wait for one of the old timers to chime in about the
ES4
days here.)
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
--
Jeremy Martin
661.312.3853
http://devsmash.com
@jmar777
--
Jeremy Martin
661.312.3853
http://devsmash.com
@jmar777
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Optional Strong Typing
I mean the parser will strip all of the typing info out before it's
compiled/interpreted.
The implication being that implementors start shipping static compilers
where this parsing/stripping takes place (i.e., as a precursory step to
being interpreted)?
but it's been made worse by ECMAScript's lack of key features
The problem with this statement is that key features is open for
interpretation.
if JS was a little more large scale development friendly (like
TypeScript), devs could just use plain ol' JS
The fact is that devs already are building large scale projects using
plain ol' JS (I myself have worked on JS projects with 100k+ loc without
feeling the need for static typing). The same goes for Python, PHP, Ruby,
etc. - this isn't an attack against static typing, but it's hardly
necessary for a language to be friendly for large scale development.
Sure, some would still use language extensions like TypeScript, but at
least it wouldn't be the defacto standard because of core inadequacies in
base language.
I'd be interested in seeing data that the de facto standard is to use
compile-to-JavaScript languages. My own experience has been quite the
opposite.
On Fri, Aug 23, 2013 at 2:24 PM, J B por...@gmail.com wrote:
@Jeremy: I mean the parser will strip all of the typing info out before
it's compiled/interpreted.
@Axel: Evolving a language standard used as broadly as ECMAScript takes
time -- I agree.
You can see TypeScript as exploring future options for ECMAScript. --
Wasn't AS3 already doing this?
Guards -- Looks good...
TypeScript tracks JavaScript very closely, I would not consider it a
different language. It's compiled, and it's one of many options available,
which presents a problem in that if one code base is written in TypeScript,
and another in JavaScript++ will they be compatible? Even if the resulting
JS is, devs will be required to learn several variants of JS. It's not that
this isn't happening elsewhere (libraries written in Java vs C#), but it's
been made worse by ECMAScript's lack of key features, which has caused a
good many of these languages to appear, and to be used. My point is, if JS
was a little more large scale development friendly (like TypeScript), devs
could just use plain ol' JS! Sure, some would still use language extensions
like TypeScript, but at least it wouldn't be the defacto standard because
of core inadequacies in base language.
On Fri, Aug 23, 2013 at 1:06 PM, Jeremy Martin jmar...@gmail.com wrote:
I mean it's a parse error that will throw prior to attempting to execute
it. For example, consider:
(function() { var foo:String; })
This will throw an error, despite the fact that the function hasn't been
invoked. I replied in haste, though... your point is obviously valid for
other scenarios. Nonetheless, as a non-authoritative response, you're
going to need an argument far more compelling than I can think of to see
static typing seriously considered.
On Fri, Aug 23, 2013 at 2:00 PM, J B por...@gmail.com wrote:
Are you referring to browsers like Chrome that compile the JS first?
Then, yeah, I mean it shouldn't throw an error at compile time.
On Fri, Aug 23, 2013 at 12:59 PM, Jeremy Martin jmar...@gmail.comwrote:
var foo:String;
That's already a compile-time error (as opposed to runtime not sure
if that's what you meant by the interpreter throwing an error).
On Fri, Aug 23, 2013 at 1:56 PM, J B por...@gmail.com wrote:
And just to be clear, I'm not asking for run-time type checking or
coercion; I'm simply asking that the interpreter not to thrown an error
when it encounters something like this: var foo:String;
On Fri, Aug 23, 2013 at 12:45 PM, J B por...@gmail.com wrote:
For one, I wouldn't describe strong typing as a pet feature. Two,
no, as far as I know, most of those languages in that list don't offer
macros or lots of parentheses; and, if they did, then, yeah, maybe it
does
say something.
On Fri, Aug 23, 2013 at 12:41 PM, Domenic Denicola
dome...@domenicdenicola.com wrote:
In general ECMAScript lacks lots of features. You may well ask why
it doesn't have any other pet feature, and you can often point to
compile-to-JS languages that add those. This doesn't imply that the
feature
should be added to the language.
Here, let me try:
---
I'm aware of LispyScript, as well as all of these:
https://github.com/jashkenas/coffee-script/wiki/List-of-languages-that-compile-to-JS
.
But those languages appear to have been created precisely because
ECMAScript lacks features like lots of parentheses or macros. How many
of
those languages offer lots of parentheses? I count quite a few...
Doesn't
that say something?
---
The existence of a feature in other languages does not imply it
should be added to ECMAScript. You'll have to justify better than that
why
you think strong typing would be valuable to a language that has
historically rejected it. (I'll wait for one
Re: [Resurrection] Make Function.length Configurable
No problem - I've enjoyed getting a glimpse into how this process works! On Wed, Jul 17, 2013 at 5:55 PM, Rick Waldron waldron.r...@gmail.comwrote: On Wed, Jul 17, 2013 at 12:17 PM, Jeremy Martin jmar...@gmail.com wrote: An offline discussion with RW identified this as a spec bug. Filed here: https://bugs.ecmascript.org/show_bug.cgi?id=1587 Thanks again! (I see that Allen has already fixed this :D) Rick -- Jeremy Martin 661.312.3853 http://devsmash.com @jmar777 ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: [Resurrection] Make Function.length Configurable
An offline discussion with RW identified this as a spec bug. Filed here:
https://bugs.ecmascript.org/show_bug.cgi?id=1587
On Tue, Jul 16, 2013 at 4:08 PM, Jeremy Martin jmar...@gmail.com wrote:
I referenced Function.length instead of Function#length. Here's the
actually relevant spec [1]:
The value of the length property is an integer that indicates the typical
number of arguments expected by the function. However, the language permits
the function to be invoked with some other number of arguments. The
behaviour of a function when invoked on a number of arguments other than
the number specified by its length property depends on the function. This
property has the attributes { [[Writable]]: false, [[Enumerable]]: false,
[[Configurable]]: false }.
Everything else still applies. (Hopefully) goes without saying, but the
same should apply to GeneratorFunction instances as well [2].
[1] http://people.mozilla.org/~jorendorff/es6-draft.html#sec-15.3.4.1
[2] http://people.mozilla.org/~jorendorff/es6-draft.html#sec-15.19.3.4
On Tue, Jul 16, 2013 at 3:53 PM, Jeremy Martin jmar...@gmail.com wrote:
This is a resurrection of an earlier proposal from Nathan Wall [1], that
would make Function.length configurable. The initial proposal was to make
it writable, but configurable instead was suggested by Claude Pache [2].
Nathan's original post [1] does a good job of outlining the motivation,
so I won't reiterate them here. From what I can gather, making
Function.length configurable seemed to receive a positive response [3] [4]
[5], but the thread apparently died. Perhaps I just need to find a new API
paradigm, but I run into this issue on a regular basis writing callback
utilities, and would be very interested in seeing this move forward.
For convenience, the Function.length spec from the latest draft [6]:
This is a data property with a value of 1. This property has the
attributes { [[Writable]]: false, [[Enumerable]]: false, [[Configurable]]:
false }.
[1] http://www.mail-archive.com/es-discuss@mozilla.org/msg21786.html
[2] http://www.mail-archive.com/es-discuss@mozilla.org/msg21792.html
[3] http://www.mail-archive.com/es-discuss@mozilla.org/msg21793.html
[4] http://www.mail-archive.com/es-discuss@mozilla.org/msg21794.html
[5] http://www.mail-archive.com/es-discuss@mozilla.org/msg21795.html
[6] http://people.mozilla.org/~jorendorff/es6-draft.html#sec-15.3.2.2
Thanks,
--
Jeremy Martin
661.312.3853
http://devsmash.com
@jmar777
--
Jeremy Martin
661.312.3853
http://devsmash.com
@jmar777
--
Jeremy Martin
661.312.3853
http://devsmash.com
@jmar777
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
[Resurrection] Make Function.length Configurable
This is a resurrection of an earlier proposal from Nathan Wall [1], that
would make Function.length configurable. The initial proposal was to make
it writable, but configurable instead was suggested by Claude Pache [2].
Nathan's original post [1] does a good job of outlining the motivation, so
I won't reiterate them here. From what I can gather, making
Function.length configurable seemed to receive a positive response [3] [4]
[5], but the thread apparently died. Perhaps I just need to find a new API
paradigm, but I run into this issue on a regular basis writing callback
utilities, and would be very interested in seeing this move forward.
For convenience, the Function.length spec from the latest draft [6]:
This is a data property with a value of 1. This property has the attributes
{ [[Writable]]: false, [[Enumerable]]: false, [[Configurable]]: false }.
[1] http://www.mail-archive.com/es-discuss@mozilla.org/msg21786.html
[2] http://www.mail-archive.com/es-discuss@mozilla.org/msg21792.html
[3] http://www.mail-archive.com/es-discuss@mozilla.org/msg21793.html
[4] http://www.mail-archive.com/es-discuss@mozilla.org/msg21794.html
[5] http://www.mail-archive.com/es-discuss@mozilla.org/msg21795.html
[6] http://people.mozilla.org/~jorendorff/es6-draft.html#sec-15.3.2.2
Thanks,
--
Jeremy Martin
661.312.3853
http://devsmash.com
@jmar777
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: [Resurrection] Make Function.length Configurable
I referenced Function.length instead of Function#length. Here's the
actually relevant spec [1]:
The value of the length property is an integer that indicates the typical
number of arguments expected by the function. However, the language permits
the function to be invoked with some other number of arguments. The
behaviour of a function when invoked on a number of arguments other than
the number specified by its length property depends on the function. This
property has the attributes { [[Writable]]: false, [[Enumerable]]: false,
[[Configurable]]: false }.
Everything else still applies. (Hopefully) goes without saying, but the
same should apply to GeneratorFunction instances as well [2].
[1] http://people.mozilla.org/~jorendorff/es6-draft.html#sec-15.3.4.1
[2] http://people.mozilla.org/~jorendorff/es6-draft.html#sec-15.19.3.4
On Tue, Jul 16, 2013 at 3:53 PM, Jeremy Martin jmar...@gmail.com wrote:
This is a resurrection of an earlier proposal from Nathan Wall [1], that
would make Function.length configurable. The initial proposal was to make
it writable, but configurable instead was suggested by Claude Pache [2].
Nathan's original post [1] does a good job of outlining the motivation, so
I won't reiterate them here. From what I can gather, making
Function.length configurable seemed to receive a positive response [3] [4]
[5], but the thread apparently died. Perhaps I just need to find a new API
paradigm, but I run into this issue on a regular basis writing callback
utilities, and would be very interested in seeing this move forward.
For convenience, the Function.length spec from the latest draft [6]:
This is a data property with a value of 1. This property has the
attributes { [[Writable]]: false, [[Enumerable]]: false, [[Configurable]]:
false }.
[1] http://www.mail-archive.com/es-discuss@mozilla.org/msg21786.html
[2] http://www.mail-archive.com/es-discuss@mozilla.org/msg21792.html
[3] http://www.mail-archive.com/es-discuss@mozilla.org/msg21793.html
[4] http://www.mail-archive.com/es-discuss@mozilla.org/msg21794.html
[5] http://www.mail-archive.com/es-discuss@mozilla.org/msg21795.html
[6] http://people.mozilla.org/~jorendorff/es6-draft.html#sec-15.3.2.2
Thanks,
--
Jeremy Martin
661.312.3853
http://devsmash.com
@jmar777
--
Jeremy Martin
661.312.3853
http://devsmash.com
@jmar777
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Proposal: new Symbol(obj)
(a === b) = (new Symbol(a) === new Symbol(b)) Not sure I follow... so, I either I don't agree or I don't understand :). I'm having to dig deep to remember my math vocab here, but I think it may be most correct to say that the Symbol constructor, when passed an argument, should be injective [1]. That is, 1. let *F* = *new Symbol* 2. if http://en.wikipedia.org/wiki/Material_conditional *a* = *b*, then *F *(*a**)* = *F(b)* 3. if *a* != *b*, then *F(a) *!= *F(b)* In any case, I'd also say that weak maps are good enough for your use case. In some (most?) cases, but not all. There's already a consensus that the garbage collection semantics of WeakMaps aren't always appropriate [2]. By parameterizing the Symbol constructor, developers can create custom map/set types without the overhead of a Symbol Factory (as previously suggested by Allen). I believe this would be a useful building block for interesting and innovative custom types. [1]: https://en.wikipedia.org/wiki/Injective_function#Definition [2]: http://wiki.ecmascript.org/doku.php?id=harmony:simple_maps_and_sets On Mon, Jul 15, 2013 at 5:52 AM, Andreas Rossberg rossb...@google.comwrote: On 12 July 2013 22:29, Jeremy Martin jmar...@gmail.com wrote: My expectation would be that... (a === b) === (new Symbol(a) === new Symbol(b)) Nit: you probably either mean (a === b) = (new Symbol(a) === new Symbol(b)) or (Object.is(a, b)) === (new Symbol(a) === new Symbol(b)) In any case, I'd also say that weak maps are good enough for your use case. /Andreas -- Jeremy Martin 661.312.3853 http://devsmash.com @jmar777 ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Proposal: new Symbol(obj)
so, I either I don't agree or I don't understand It was the latter - I understand and agree now :) On Mon, Jul 15, 2013 at 10:03 AM, Andreas Rossberg rossb...@google.comwrote: On 15 July 2013 15:49, Jeremy Martin jmar...@gmail.com wrote: (a === b) = (new Symbol(a) === new Symbol(b)) Not sure I follow... so, I either I don't agree or I don't understand :). I'm having to dig deep to remember my math vocab here, but I think it may be most correct to say that the Symbol constructor, when passed an argument, should be injective [1]. That is, 1. let F = new Symbol 2. if a = b, then F(a) = F(b) 3. if a != b, then F(a) != F(b) I agree, but the problem is that JavaScript's === is not an equivalence relation, due to the dreaded NaN !== NaN that IEEE invented in some delirium. So you cannot define injectivity based on it. You merely get an implication for the above, which is what the = was supposed to encode. Object.is OTOH implements a proper equivalence relation, i.e. a = in the mathematical sense. It only differs from === by having a sane semantics for NaN. But as I said, I was merely picking a nit. /Andreas -- Jeremy Martin 661.312.3853 http://devsmash.com @jmar777 ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: How primitive are Symbols? Bignums? etc
s === Object(s) This should throw a TypeError. In the case of a Symbol, `Object(*value*)` results in `ToObject(*value*)` [1]. And, in the case of Symbol, ToObject should throw a TypeError [2]. [1] http://people.mozilla.org/~jorendorff/es6-draft.html#sec-15.2.1.1 [2] http://people.mozilla.org/~jorendorff/es6-draft.html#sec-9.1.9 On Mon, Jul 15, 2013 at 10:48 AM, Mark S. Miller erig...@google.com wrote: Given that s is a Symbol and b is a Bignum, is s === Object(s) ? Is b === Object(b) ? The reason I ask is that x === Object(x) is often used to distinguish primitive values from objects. The other thing that's often used is typeof, but these uses of typeof usually assume that the full range of possible answers is already known. If we're going to be expanding the typeof answers, then we need guidance on how to write this test now (es5) such that it stays robust. -- Cheers, --MarkM ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss -- Jeremy Martin 661.312.3853 http://devsmash.com @jmar777 ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: How primitive are Symbols? Bignums? etc
That's unpleasant. [...] Much old code will break.
Indeed. I hadn't actually noticed that change until just now. It looks
like ES6 code can take advantage of Object.isObject(), which seems to
delegate the work to Type(*x*) [1]. It wasn't overwhelmingly clear to me,
but I would assume `Object.isObject('foo') === false` and
`Object.isObject(new String('foo')) === true`.
Has anyone surveyed/looked into what the fallout of throwing on stuff like
`Object(undefined)` will be?
[1] http://people.mozilla.org/~jorendorff/es6-draft.html#sec-8
On Mon, Jul 15, 2013 at 11:09 AM, Mark S. Miller erig...@google.com wrote:
I see. That's unpleasant. In ES5, Object(x) can never throw, and so the
code paths using |x === Object(x)| are not prepared for a throw. Much old
code will break.
On Mon, Jul 15, 2013 at 8:01 AM, Jeremy Martin jmar...@gmail.com wrote:
s === Object(s)
This should throw a TypeError. In the case of a Symbol, `Object(*value*)`
results in `ToObject(*value*)` [1]. And, in the case of Symbol,
ToObject should throw a TypeError [2].
[1] http://people.mozilla.org/~jorendorff/es6-draft.html#sec-15.2.1.1
[2] http://people.mozilla.org/~jorendorff/es6-draft.html#sec-9.1.9
On Mon, Jul 15, 2013 at 10:48 AM, Mark S. Miller erig...@google.comwrote:
Given that s is a Symbol and b is a Bignum, is
s === Object(s)
?
Is
b === Object(b)
?
The reason I ask is that x === Object(x) is often used to distinguish
primitive values from objects. The other thing that's often used is typeof,
but these uses of typeof usually assume that the full range of possible
answers is already known. If we're going to be expanding the typeof
answers, then we need guidance on how to write this test now (es5) such
that it stays robust.
--
Cheers,
--MarkM
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
--
Jeremy Martin
661.312.3853
http://devsmash.com
@jmar777
--
Cheers,
--MarkM
--
Jeremy Martin
661.312.3853
http://devsmash.com
@jmar777
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: How primitive are Symbols? Bignums? etc
Ahh, thanks. Somehow I read that as `Object(undefined)` -
ObjectCreate(undefined)` - throw, but that's not the case.
On Mon, Jul 15, 2013 at 11:39 AM, Mark S. Miller erig...@google.com wrote:
Object(undefined) would still not throw:
http://people.mozilla.org/~jorendorff/es6-draft.html#sec-15.2.1.1 step 1
On Mon, Jul 15, 2013 at 8:37 AM, Jeremy Martin jmar...@gmail.com wrote:
That's unpleasant. [...] Much old code will break.
Indeed. I hadn't actually noticed that change until just now. It looks
like ES6 code can take advantage of Object.isObject(), which seems to
delegate the work to Type(*x*) [1]. It wasn't overwhelmingly clear to
me, but I would assume `Object.isObject('foo') === false` and
`Object.isObject(new String('foo')) === true`.
Has anyone surveyed/looked into what the fallout of throwing on stuff
like `Object(undefined)` will be?
[1] http://people.mozilla.org/~jorendorff/es6-draft.html#sec-8
On Mon, Jul 15, 2013 at 11:09 AM, Mark S. Miller erig...@google.comwrote:
I see. That's unpleasant. In ES5, Object(x) can never throw, and so the
code paths using |x === Object(x)| are not prepared for a throw. Much old
code will break.
On Mon, Jul 15, 2013 at 8:01 AM, Jeremy Martin jmar...@gmail.comwrote:
s === Object(s)
This should throw a TypeError. In the case of a Symbol, `Object(*value
*)` results in `ToObject(*value*)` [1]. And, in the case of Symbol,
ToObject should throw a TypeError [2].
[1] http://people.mozilla.org/~jorendorff/es6-draft.html#sec-15.2.1.1
[2] http://people.mozilla.org/~jorendorff/es6-draft.html#sec-9.1.9
On Mon, Jul 15, 2013 at 10:48 AM, Mark S. Miller erig...@google.comwrote:
Given that s is a Symbol and b is a Bignum, is
s === Object(s)
?
Is
b === Object(b)
?
The reason I ask is that x === Object(x) is often used to distinguish
primitive values from objects. The other thing that's often used is
typeof,
but these uses of typeof usually assume that the full range of possible
answers is already known. If we're going to be expanding the typeof
answers, then we need guidance on how to write this test now (es5) such
that it stays robust.
--
Cheers,
--MarkM
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
--
Jeremy Martin
661.312.3853
http://devsmash.com
@jmar777
--
Cheers,
--MarkM
--
Jeremy Martin
661.312.3853
http://devsmash.com
@jmar777
--
Cheers,
--MarkM
--
Jeremy Martin
661.312.3853
http://devsmash.com
@jmar777
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: generators vs forEach
Alternatively, could `yield` simply be lexically bound to the nearest
GeneratorFunction scope, rather than the nearest Function?
E.g., instead of:
suspend(function* (resume) {
yield setTimeout(resume, 1000);
console.log('foo');
yield setTimeout(resume, 1000);
console.log('bar');
})();
... we could write:
suspend(function* (resume) {
['foo', 'bar'].forEach(function(word) {
yield setTimeout(resume, 1000);
console.log(word);
});
})();
The current state of things here is pretty ugly, and I'd really like to
avoid having to add something like `suspend.forEach(Array,
GeneratorFunction)` with `yield*` in the body.
On Mon, Jul 15, 2013 at 11:33 AM, Claus Reinke claus.rei...@talk21.comwrote:
[prompted by this nodejs list thread Weird error with generators (using
suspend or galaxy)
https://groups.google.com/**forum/#!topic/nodejs/**9omOdgSPkz4https://groups.google.com/forum/#!topic/nodejs/9omOdgSPkz4]
1. higher order functions are used to model control structures
2. generators/yield are designed to allow for suspend/resume
of control structure code
These two statements come in conflict if one considers the restriction
that generators be based on flat continuations, which is sufficient to
span built-in control structures like for but not predefined control
structures like forEach. The support for nested generators (yield*)
differs from normal function call operation.
I have not seen this conflict discussed here, so I wanted to raise it
in case it was an oversight and something can be done about it. As
far as I can tell, there are two issues:
- current predefined operations like forEach, map, filter, ..
are not fully integrated with generators, even though they
model synchronous operations; expecting users to duplicate
their functionality for use with generators seems wrong;
- is it even possible to define higher-order operations that can be
used both normally (without yield inside their callbacks, without
yield wrapping their result) and with generators (with yield
inside their callbacks, with yield wrapping their result)?
Claus
http://clausreinke.github.com/
__**_
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/**listinfo/es-discusshttps://mail.mozilla.org/listinfo/es-discuss
--
Jeremy Martin
661.312.3853
http://devsmash.com
@jmar777
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: generators vs forEach
Correct me if I'm wrong, but wouldn't the lexical-scoping restraint satisfy
the shallow generator requirement? As I understand it, the issue with deep
generators and CPS transformations is that the transformations have to be
applied to functions that aren't even lexically inside the
GeneratorFunction. Additionally, can't the nested CPS transformations
issue by alleviated with a reference to the GeneratorFunction stack frame
itself (a la SpiderMonkey)?
On Mon, Jul 15, 2013 at 12:45 PM, Mark S. Miller erig...@google.com wrote:
This would make generators deep, violating the non-interleaving
assumptions of intermediate callers on the call stack. This is why we
accepted generators only on condition that they be shallow. We knew at the
time that this privileges built-in control structures over user defined
ones. The alternative would have been to omit generators completely. We
agree that shallow generators were worth it, despite this non-uniformity.
Put another way, shallow generators are equivalent to a local cps
transform of the generator function itself. Deep generators would require
the equivalent of CPS transforming the world -- violating the stateful
assumptions of existing code.
On Mon, Jul 15, 2013 at 9:09 AM, Jeremy Martin jmar...@gmail.com wrote:
Alternatively, could `yield` simply be lexically bound to the nearest
GeneratorFunction scope, rather than the nearest Function?
E.g., instead of:
suspend(function* (resume) {
yield setTimeout(resume, 1000);
console.log('foo');
yield setTimeout(resume, 1000);
console.log('bar');
})();
... we could write:
suspend(function* (resume) {
['foo', 'bar'].forEach(function(word) {
yield setTimeout(resume, 1000);
console.log(word);
});
})();
The current state of things here is pretty ugly, and I'd really like to
avoid having to add something like `suspend.forEach(Array,
GeneratorFunction)` with `yield*` in the body.
On Mon, Jul 15, 2013 at 11:33 AM, Claus Reinke
claus.rei...@talk21.comwrote:
[prompted by this nodejs list thread Weird error with generators (using
suspend or galaxy)
https://groups.google.com/**forum/#!topic/nodejs/**9omOdgSPkz4https://groups.google.com/forum/#!topic/nodejs/9omOdgSPkz4]
1. higher order functions are used to model control structures
2. generators/yield are designed to allow for suspend/resume
of control structure code
These two statements come in conflict if one considers the restriction
that generators be based on flat continuations, which is sufficient to
span built-in control structures like for but not predefined control
structures like forEach. The support for nested generators (yield*)
differs from normal function call operation.
I have not seen this conflict discussed here, so I wanted to raise it
in case it was an oversight and something can be done about it. As
far as I can tell, there are two issues:
- current predefined operations like forEach, map, filter, ..
are not fully integrated with generators, even though they
model synchronous operations; expecting users to duplicate
their functionality for use with generators seems wrong;
- is it even possible to define higher-order operations that can be
used both normally (without yield inside their callbacks, without
yield wrapping their result) and with generators (with yield
inside their callbacks, with yield wrapping their result)?
Claus
http://clausreinke.github.com/
__**_
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/**listinfo/es-discusshttps://mail.mozilla.org/listinfo/es-discuss
--
Jeremy Martin
661.312.3853
http://devsmash.com
@jmar777
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
--
Cheers,
--MarkM
--
Jeremy Martin
661.312.3853
http://devsmash.com
@jmar777
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: generators vs forEach
That means CPS transforming functions based on whether they call a
yielding function.
Well, yes :) Admittedly, that does seem messy. Not to sound defeatist,
but I'm sensing that I don't actually have the necessary knowledge to
further argue this. I'll just end with saying that it'll be unfortunate if
we're going to have to endure the clunkiness of nested generators anywhere
higher-order functions are called for. Regardless of whatever solutions
may or may not be appropriate, I at a minimum echo Claus' sentiment - it
seems like there's a nice opportunity here to improve the modeling of
control structures.
On Mon, Jul 15, 2013 at 3:01 PM, Brandon Benvie bben...@mozilla.com wrote:
On 7/15/2013 10:24 AM, Jeremy Martin wrote:
Correct me if I'm wrong, but wouldn't the lexical-scoping restraint
satisfy the shallow generator requirement? As I understand it, the issue
with deep generators and CPS transformations is that the transformations
have to be applied to functions that aren't even lexically inside the
GeneratorFunction. Additionally, can't the nested CPS transformations
issue by alleviated with a reference to the GeneratorFunction stack frame
itself (a la SpiderMonkey)?
Consider the following:
function* yieldEach(array){
array.forEach(n = {
yield n;
});
}
In order for this to work, not only does `yieldEach` have to be suspended
for the inner yield, but forEach does as well. That means CPS transforming
functions based on whether they call a yielding function.
__**_
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/**listinfo/es-discusshttps://mail.mozilla.org/listinfo/es-discuss
--
Jeremy Martin
661.312.3853
http://devsmash.com
@jmar777
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Proposal: new Symbol(obj)
In brief: allow Symbol's to be constructed with a single parameter, with
the following behavior:
var obj = {};
undefined
new Symbol({}) === new Symbol({})
false
new Symbol(obj) === new Symbol(obj)
true
Motivation: the ability to construct equal Symbols gives us the necessary
building blocks to build custom maps with semantics very similar to Simple
Maps[1]:
function ObjectMap() {
this.map = {};
}
SimpleMap.prototype.set = function(objKey, val) {
this.map[new Symbol(objKey)] = val;
};
SimpleMap.prototype.get = function(objKey) {
return this.map[new Symbol(objKey)];
};
At a surface level, this seems more novelty than anything else, but I think
it's a useful primitive for building more complex and robust features on
top of Symbols. Thoughts?
[1] http://wiki.ecmascript.org/doku.php?id=harmony:simple_maps_and_sets
--
Jeremy Martin
661.312.3853
http://devsmash.com
@jmar777
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Proposal: new Symbol(obj)
Good point, that's definitely a usable solution (also a better
representation of what I was attempting to describe).
I'd still be interested in a less-verbose/more-efficient approach using the
Symbol constructor, but it may not be a common enough scenario to justify
it when a workaround does exist.
On Fri, Jul 12, 2013 at 3:32 PM, Allen Wirfs-Brock al...@wirfs-brock.comwrote:
On Jul 12, 2013, at 12:14 PM, Jeremy Martin wrote:
In brief: allow Symbol's to be constructed with a single parameter, with
the following behavior:
var obj = {};
undefined
new Symbol({}) === new Symbol({})
false
new Symbol(obj) === new Symbol(obj)
true
You can use a WeakMap to build your own object-selected Symbol factory:
let known = new WeakMap;
function ObjSymFactory(obj) {
//handle obj === undefined however you want
let sym = known.get(obj);
If (!sym) {
sym = new Symbol;
known.set(obj,sym);
}
return sym;
}
Allen
--
Jeremy Martin
661.312.3853
http://devsmash.com
@jmar777
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Proposal: new Symbol(obj)
My expectation would be that...
(a === b) === (new Symbol(a) === new Symbol(b))
I.e., `new Symbol(a) === new Symbol(b)` iff `a === b`. This satisfies the
strings/integers scenario, but, of course, fails your WeakMap garbage
collection semantics. You need WeakSymbolMaps (+ this proposal) :)
On Fri, Jul 12, 2013 at 4:15 PM, K. Gadd k...@luminance.org wrote:
I would welcome (with fanfare and parades) a new Symbol(obj) that worked
for strings and integers. Such is not possible using the WeakMap shim
(you'd have to detect the type of the value and have multiple dictionaries,
or something, and you'd leak the symbols forever...)
Of course, what that means is I'm asking for weakly cached symbols with
referential identity, which means it would allow detecting garbage
collections, so this is probably around the point where people chime in and
say it's not possible. Oh well. :(
On Fri, Jul 12, 2013 at 12:42 PM, Jeremy Martin jmar...@gmail.com wrote:
Good point, that's definitely a usable solution (also a better
representation of what I was attempting to describe).
I'd still be interested in a less-verbose/more-efficient approach using
the Symbol constructor, but it may not be a common enough scenario to
justify it when a workaround does exist.
On Fri, Jul 12, 2013 at 3:32 PM, Allen Wirfs-Brock al...@wirfs-brock.com
wrote:
On Jul 12, 2013, at 12:14 PM, Jeremy Martin wrote:
In brief: allow Symbol's to be constructed with a single parameter, with
the following behavior:
var obj = {};
undefined
new Symbol({}) === new Symbol({})
false
new Symbol(obj) === new Symbol(obj)
true
You can use a WeakMap to build your own object-selected Symbol factory:
let known = new WeakMap;
function ObjSymFactory(obj) {
//handle obj === undefined however you want
let sym = known.get(obj);
If (!sym) {
sym = new Symbol;
known.set(obj,sym);
}
return sym;
}
Allen
--
Jeremy Martin
661.312.3853
http://devsmash.com
@jmar777
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
--
Jeremy Martin
661.312.3853
http://devsmash.com
@jmar777
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Object#extra hazard
Events are already part of the interface of objects as people use them:
* in Node.js, events are documented at the same level than properties and
methods.
* In new FirefoxOS WebAPIs, pretty much every new object inherits from
EventTarget.
I don't think that Node.js is a relevant example here. Events are only
exposed on instances (or subclasses) of EventEmitter. This happens to
include a lot of the core objects, but it is nonetheless implemented via
the [[Prototype]] and object-level properties (rather than anything
resembling a MOP). I'm less familiar with FirefoxOS WebAPIs, but the same
appears to be true here as well, unless I'm missing something.
On Wed, Jul 10, 2013 at 1:33 PM, David Bruant bruan...@gmail.com wrote:
Le 10/07/2013 16:53, Andrea Giammarchi a écrit :
Just a humble attempt to propose some addiction to the `Object.prototype`
I already know many will kill me for even trying to ...
**tl;dr** - everything proposed can be already tested through this
utility called [eddy.js](https://github.com/**WebReflection/eddy#event-**
driven-js https://github.com/WebReflection/eddy#event-driven-js)
### Event Target All The Things
One of the most widely adopted API in JavaScript world is based on a
combination of these methods:
* `.on(type, handler[, capture])` used as equivalent of
`addEventListener` in the DOM namespace, also used in every library that
would like to be event driven. Smart enough to avoid duplicated entries for
the same handler over the same event type.
* `.once(type, handler[, capture])` used to simplify `.on()` within an
`.off()` at the top of the invocation to ensure a one shot only event
* `.off(type, handler[, capture])` to remove a previously set event
handler or silently failif not present
* `.emit(type[, arg1][, argN])` directly from node.js world where almost
every object is an EventTarget and EventEmitter anyhow since it's needed
and has been proven it's a highly appreciated/welcome approach.
* `.trigger(type[, data])` similar to `.emit()` except it triggers/fires
an event object with some extra method such `evt.stopImmediatePropagation(
**)` or others DOM related when the event comes from DOM
The proposed implementation lazily assign internal listeners event
handlers only once these methods are invoked for the very first time.
This makes every object
... inheriting from Object.prototype...
able to be promoted at runtime as event emitter:
```javascript
var o = {};
// o is just an object
o.on('event-name', console.log.bind(console));
// now o has internals able to work with handlers
o.trigger('event-name');
// will log an Event object
```
I believe events should be part of the object MOP interface (regardless of
the [[Prototype]] value). Events are already part of the interface of
objects as people use them:
* in Node.js, events are documented at the same level than properties and
methods.
* In new FirefoxOS WebAPIs, pretty much every new object inherits from
EventTarget.
Also, Object properties now have their events (Object.observe), following
DOM mutation-related events (DOM Observers API). It won't take long before
someone asks for mutation events in ES6 Maps and Sets...
Anyway, I agree with the intent, but I would put the tool at a lower-level
if given the choice.
David
__**_
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/**listinfo/es-discusshttps://mail.mozilla.org/listinfo/es-discuss
--
Jeremy Martin
661.312.3853
http://devsmash.com
@jmar777
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Object#extra hazard
(like, say, the way Jeremy Martin proposed)
FTR, I haven't proposed anything just yet :)
Although if I did, I think I would be more fond of something like:
Object.mixin({ foo: 'bar' }, EventEmitter);
... that is, I can see the value of events as an object-level API that
doesn't imply actual inheritance from something else. The use of `mixin`
is probably a distraction here, but the main point is that it's opt-in.
Events inherently have semantics around them, and they're certainly not
universal semantics for objects. In fact, event semantics aren't even
universal for events (e.g., bubbling). It seems better to me to have some
sort of explicit contract before those semantics kick in.
On Wed, Jul 10, 2013 at 2:31 PM, David Bruant bruan...@gmail.com wrote:
Le 10/07/2013 20:27, Anne van Kesteren a écrit :
On Wed, Jul 10, 2013 at 2:19 PM, David Bruant bruan...@gmail.com wrote:
This madness really has to stop. We need first class events (and I'm
praying
for a way to retrofit them into the DOM if possible)
If you don't do the latter, I wonder how you'll achieve the former.
The former can be achieved independently of anything else. It only
requires for the ECMA 262 spec to say now, objects have events! (like,
say, the way Jeremy Martin proposed).
Whether that event system works well and intelligently with the current
event systems (DOM especially since it has lots of quirks) is a different
matter.
But I agree it would be wise to do both at the same time.
David
--
Jeremy Martin
661.312.3853
http://devsmash.com
@jmar777
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Object#extra hazard
the DOM, behind WebIDL,
and ECMAScript ... something I know already historically incompatible,
that's why I've proposed new names hopefully one day (and hopefully soon)
in core, something that will be inherited in current implementation in any
case, as it was in my case simply polluting the `Object.prototype` with
those non enumerable properties luckily inherited in hosted DOM objects
too.
best regards
On Wed, Jul 10, 2013 at 12:46 PM, Matthew Robb
matthewwr...@gmail.comwrote:
You can do chainability at object define time with the sugar form:
var obj = {
on type1(){},
on type2(){},
on type3(){}
}
This is the dark days of DOM element properties as event handlers:
elem.onclick...
Assigning to this paves over the previous assignment, leaving no way to
have multiple handlers registered for the same event type.
OR add to it using one of the following options:
Object.mixin(obj, {
on type1(){},
on type2(){},
on type3(){}
})
obj.{
on type1(){},
on type2(){},
on type3(){}
}
obj := {
on type1(){},
on type2(){},
on type3(){}
}
On Wed, Jul 10, 2013 at 12:41 PM, Andrea Giammarchi
andrea.giammar...@gmail.com wrote:
my implementation works already with `DOM` nodes and browser
environment, including `window`.
I've also already written an `EventTarget` mixin object but in my
case I'd use that via `Object.mixin(Object.prototype, EventTarget);`
'cause
almost every object I use in my logic should be observed or should emit
something to some other object.
Standard lib approach (a la node) works today and tomorrow.
Of course Dictionaries are out of the game but that's OK, as long as
it's possible to promote them later on via `Object.setPrototypeOf(dict,
Object.proottype)`
I find the `Object.addEventListener(obj, type, handler)` approach
very boring for the simple reason that it does not make sense to use
chainability there, another de-facto thing when it comes to events.
It's also (subjectively) hideous.
```javascript
// current eddy.js status
var obj = {}
.on(type1, handler1)
.on(type2, handler2)
.on(type3, handler3)
;
```
That's great for your use case, but I would never want this by default.
Rick
(snip)
___
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
--
Jeremy Martin
661.312.3853
http://devsmash.com
@jmar777
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re:
is quite another thing.
It is how you do (single) inheritance in JS. In your OP, you say I
think we should wait for some patterns to gain a foothold in the
wild. Single inheritance via prototype chains is an immensely
popular pattern for this kind of thing. You do qualify your statement
by saying we should wait for *good* patterns, but single inheritance
is perfectly good for some things, and adequate for quite a bit else.
There are certainly better patterns, but none of them have gotten wide
traction yet. We definitely want to pursue something like mixins in
the future, but in ES6 we purposely went for a maximally minimal
class syntax, adding as little as possible while still achieving the
readability and usability gains of having a dedicated syntax.
For example, when we come up with a good mixin pattern, adding it to
the class syntax is as easy as doing class Foo mixin Bar, Baz, Qux
{...}. No clash with extends; it just slots in cleanly.
My arguments (and a few suggested alternatives) are in the video.
If you're going to blow off what I have to say about it because you
don't
have time to watch a video, I guess the conversation is over. =)
In our private conversation, I just asked for a text version, as it's
several times faster to read text than listen to a talk. It would
likely take you roughly as much time to write out the points you want
us to take from the video as I, individually, would save by being able
to read them instead of having to watch the video. When multiplied
over the whole mailing list (or at least the people interested enough
in this thread to care), the balance of time is clearly on the side of
just spend the time writing out what you want to say.
~TJ
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
--
Jeremy Martin
661.312.3853
http://devsmash.com
@jmar777
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
