Re: Break out of non-loops
That is a whole different deal, closer to Python's `StopIteration` than standard control flow. On Fri, Oct 27, 2017, 20:15 liorean wrote: > The places where break and continue would be most interesting to me in > non-loops would be for dynamic flow control in nested functions or in > callbacks, for example to use in mapping or folding functions, not in > statement context with lexical blocks and labels. Look at Ruby's > next/break/redo/retry for what I mean. > -- > David "liorean" Andersson > ___ > 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: Break out of non-loops
The places where break and continue would be most interesting to me in non-loops would be for dynamic flow control in nested functions or in callbacks, for example to use in mapping or folding functions, not in statement context with lexical blocks and labels. Look at Ruby's next/break/redo/retry for what I mean. -- David "liorean" Andersson ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: How it feels to learn JavaScript in 2016
Best response I've seen: https://medium.freecodecamp.org/javascript-fatigue-fatigue-66ffb619f6ce I'd just like to thank TC39 for not breaking compatibility. All the niche old libraries I use that were written in ES5 still work in my ES6+ projects with no issues. The ability to take it or leave it when it comes to new features makes the changes easy as pie On Oct 28 2017, at 8:26 am, Florian Bösch wrote: > I use a simple build script/requirement/module system I wrote myself in a few > dozen lines that does things the way I like it. I find the permanent churn of > pointless new flavors of the same thing annoying and distracting, whatever > happened to writing code and be done with it, programming isn't spending time > tweaking your super hip setup so long by the time you're done something new > is now the new hotness. > > On Fri, Oct 27, 2017 at 12:38 AM, J Decker (mailto:d3c...@gmail.com)> wrote: > > (humor?) > > https://hackernoon.com/how-it-feels-to-learn-javascript-in-2016-d3a717dd577f > > > > It all seemed so simple > > ___ > > es-discuss mailing list > > es-discuss@mozilla.org (mailto:es-discuss@mozilla.org) > > https://mail.mozilla.org/listinfo/es-discuss > > > > ___ > es-discuss mailing list > es-discuss@mozilla.org > https://mail.mozilla.org/listinfo/es-discuss ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: How it feels to learn JavaScript in 2016
I use a simple build script/requirement/module system I wrote myself in a few dozen lines that does things the way I like it. I find the permanent churn of pointless new flavors of the same thing annoying and distracting, whatever happened to writing code and be done with it, programming isn't spending time tweaking your super hip setup so long by the time you're done something new is now the new hotness. On Fri, Oct 27, 2017 at 12:38 AM, J Decker wrote: > (humor?) https://hackernoon.com/how-it-feels-to-learn-javascript-in-2016- > d3a717dd577f > > It all seemed so simple > > ___ > es-discuss mailing list > es-discuss@mozilla.org > https://mail.mozilla.org/listinfo/es-discuss > > ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Re: Array.prototype.mapOn method
I found myself using this type of conditionals a lot so i thought it would be a nice addition to the native array arsenal (+1 for getting rid of the if statements), but after reading your comments i believe you are correct. It might be better for such utilities to belong in a small wrapper or part of a utility library like lodash. Cheers! Ahmad Bamieh, ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Array.prototype.mapOn method
On Fri, Oct 27, 2017 at 8:17 AM, Peter Jaszkowiak wrote:
>
> Actually flatMap isn't even needed. My question is, why use this over a
> normal map with a conditional? It doesn't seem to really save any space.
Right. The example given:
```
exampleArray.mapOn(Math.sqrt, Number.isInteger); // [1, 1.414, 3, "A",
"B", "C"];
```
can be written with today's code as just:
```
exampleArray.map(x=>Number.isInteger(x) ? Math.sqrt(x) : x);
```
You're paying only a tiny handful of additional characters for this.
-
And in any case, specializing this use-case to Array.map only isn't
too great. This sort of "conditionally call this function" ability
would be useful more generally, with something like:
```
function onlyIf(cond, func) {
return (...x)=>cond(...x) ? func(...x) : x;
}
exampleArray.map(onlyIf(Number.isInteger, Math.sqrt));
```
Feel free to write this into your own code. (Or get super-fancy and
put it on Function.prototype, so you can write
`.map(Math.sqrt.onlyIf(Number.isInteger))` ^_^)
~TJ
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Re: Array.prototype.mapOn method
I'd be -1 on adding something like this to the language. This is better solved with a library. Transducers are a much better general solution than by stacking or adding special array functions. You don't want to solve the "map with filter" case, since there are many, many more combinations (take after map, filter on map, group with map, etc.). Some details on transducers: https://clojure.org/reference/transducers https://github.com/cognitect-labs/transducers-js ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Break out of non-loops
On Fri, Oct 27, 2017 at 8:47 AM, Sébastien Doeraene
wrote:
> This is already possible:
>
> $ node
> > console.log('one'); *foo:* { console.log('two'); *break foo;*
> console.log('three'); }; console.log('four')
> one
> two
> four
>
>
probably just me, but this makes it very unobvious where the break goes
to... I'd rather see as a matter of style
console.log('one'); *do*{ console.log('two'); *break;* console.log('three');
}while(false); console.log('four')
but again; probably just my C basis.
Cheers,
> Sébastien
>
> On Fri, Oct 27, 2017 at 5:40 PM, Sebastian Malton
> wrote:
>
>> Something that is very useful that was recently released into Rust was
>> the idea of using a break statement to break out of the current level. This
>> is already the case for loops but in Rust it was extended to all statements
>> encased in {}.
>>
>> This would make some code a lot easier to understand as it can eliminate
>> flag variables
>>
>> ___
>> es-discuss mailing list
>> es-discuss@mozilla.org
>> https://mail.mozilla.org/listinfo/es-discuss
>>
>>
>
> ___
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Break out of non-loops
That is already supported in JS, for all statements. Even
label: break label;
is legal in JavaScript, and a convoluted way to write a nop.
On 27 October 2017 at 17:40, Sebastian Malton wrote:
> Something that is very useful that was recently released into Rust was the
> idea of using a break statement to break out of the current level. This is
> already the case for loops but in Rust it was extended to all statements
> encased in {}.
>
> This would make some code a lot easier to understand as it can eliminate
> flag variables
>
> ___
> 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: Break out of non-loops
This is already possible:
$ node
> console.log('one'); *foo:* { console.log('two'); *break foo;*
console.log('three'); }; console.log('four')
one
two
four
Cheers,
Sébastien
On Fri, Oct 27, 2017 at 5:40 PM, Sebastian Malton
wrote:
> Something that is very useful that was recently released into Rust was the
> idea of using a break statement to break out of the current level. This is
> already the case for loops but in Rust it was extended to all statements
> encased in {}.
>
> This would make some code a lot easier to understand as it can eliminate
> flag variables
>
> ___
> 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
Break out of non-loops
Something that is very useful that was recently released into Rust was the idea of using a break statement to break out of the current level. This is already the case for loops but in Rust it was extended to all statements encased in {}.This would make some code a lot easier to understand as it can eliminate flag variables ___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Array.prototype.mapOn method
Actually flatMap isn't even needed. My question is, why use this over a
normal map with a conditional? It doesn't seem to really save any space.
Is there any prior art? Do a lot of people use this kind of thing in ramda,
lodash, etc?
On Oct 27, 2017 09:11, "Ahmad Bamieh" wrote:
Can you elaborate?
`mapOn` will apply the map only if the item passes the condition, `flatMap`
has a different use case.
I'm referring to this flatMap implementation: https://gist.github.com/
samgiles/762ee337dff48623e729
Cheers!
Ahmad Bamieh,
On Fri, Oct 27, 2017 at 6:02 PM, Peter Jaszkowiak
wrote:
> I think flatMap fills this use case pretty well.
>
> On Oct 27, 2017 08:56, "Ahmad Bamieh" wrote:
>
>> Hello,
>>
>> This method maps over an array of items that meet a certain condition,
>> otherwise just pass the item as is. It is a nice feature to have along with
>> map, filter, and other functional methods on the array prototype.
>> *Description*
>> Map over an array of items:
>> - If the item meets the condition, apply the callback
>> - If the item does not meet the condition return the item without any
>> transformation.
>> *Example*
>> ```
>> const exampleArray = [1, 2, 9, "C", "B", "C"];
>> exampleArray.mapOn(Math.sqrt, Number.isInteger); // [1, 1.414, 3, "A",
>> "B", "C"];
>> ```
>> *Parameters*
>> *- callback*
>> Function that produces an element of the new Array, taking three
>> arguments:
>> * - currentValue*
>>The current element being processed in the array.
>> * - index*
>>The index of the current element being processed in the array.
>> * - array*
>>The array map was called upon.
>> *- condition*
>> Function perdicate, if returned value is truthy, the callback is
>> applied, taking three arguments:
>> * - currentValue*
>>The current element being processed in the array.
>> * - index*
>>The index of the current element being processed in the array.
>> * - array*
>>The array map was called upon.
>> *- thisArg*
>> Optional. Value to use as this when executing callback.
>>
>> *Return value*
>> A new array with each element being the result of the callback function
>> if it meets the condition, otherwise the same item is returned.
>>
>> *Code / Polyfill *
>> Array.prototype.mapOn = function(callback, condition, thisArg=this) {
>> return this.map((currentValue, index, array) => {
>> if(condition(currentValue, index, array)) {
>> return callback.call(thisArg, currentValue, index, array)
>> }
>> return currentValue
>> })
>> }
>>
>>
>> *Link to Gist*
>>
>> https://gist.github.com/Bamieh/9fccbf4bc394d0da2fd0c8bb5d314476
>>
>> Cheers!
>> Ahmad Bamieh,
>>
>> ___
>> es-discuss mailing list
>> es-discuss@mozilla.org
>> https://mail.mozilla.org/listinfo/es-discuss
>>
>>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Array.prototype.mapOn method
Hello,
This method maps over an array of items that meet a certain condition,
otherwise just pass the item as is. It is a nice feature to have along with
map, filter, and other functional methods on the array prototype.
*Description*
Map over an array of items:
- If the item meets the condition, apply the callback
- If the item does not meet the condition return the item without any
transformation.
*Example*
```
const exampleArray = [1, 2, 9, "C", "B", "C"];
exampleArray.mapOn(Math.sqrt, Number.isInteger); // [1, 1.414, 3, "A", "B",
"C"];
```
*Parameters*
*- callback*
Function that produces an element of the new Array, taking three
arguments:
* - currentValue*
The current element being processed in the array.
* - index*
The index of the current element being processed in the array.
* - array*
The array map was called upon.
*- condition*
Function perdicate, if returned value is truthy, the callback is applied,
taking three arguments:
* - currentValue*
The current element being processed in the array.
* - index*
The index of the current element being processed in the array.
* - array*
The array map was called upon.
*- thisArg*
Optional. Value to use as this when executing callback.
*Return value*
A new array with each element being the result of the callback function if
it meets the condition, otherwise the same item is returned.
*Code / Polyfill *
Array.prototype.mapOn = function(callback, condition, thisArg=this) {
return this.map((currentValue, index, array) => {
if(condition(currentValue, index, array)) {
return callback.call(thisArg, currentValue, index, array)
}
return currentValue
})
}
*Link to Gist*
https://gist.github.com/Bamieh/9fccbf4bc394d0da2fd0c8bb5d314476
Cheers!
Ahmad Bamieh,
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: How it feels to learn JavaScript in 2016
kai zhu, it sounds like you have a bad manager who is over eagerly pushing for a disruptive transition in a well established ES5 project to new features. The way to gracefully introduce the new features is incrementally in new code, not existing code, or when modifying existing code. If your manager is pushing to translate the whole code base and you are finding that a waste of time, then that is not the fault of TC39 or the language; that is the fault of the manager. The features themselves are superior, more powerful and easier to use than the former ES5, so "everyday javascript programmers" will have a better time whether they are writing tiny or massive apps. Yes, new apps should use those features immediately, and the developers will experience the benefits, sometimes very significant On Fri, 27 Oct 2017, 11:52 am kai zhu, wrote: > in frontend-development, the majority of use-cases are for > small/medium-scale applications, where es6 toolings are inappropriate > due to their complexity. > > "reliable, well-engineered, large-scale, performant applications" are > a niche application of javascript. tc39 should focus on making lives > of everyday javascript programmers easier (who mainly want simple and > stable tooling for simple/moderate webapps), instead of catering to > niche people wanting google/facebook-scale apps. > > > On 10/27/17, Bob Myers wrote: > > If you don't like those features or the associated tooling, then don't > use > > them. > > Meanwhile, other people will be using them to build reliable, > > well-engineered, large-scale, performant applications. > > Bob > > > > On Fri, Oct 27, 2017 at 10:57 AM, kai zhu wrote: > > > >> tc39 is partly to blame for promoting the perception of javascript > >> language instability, which promotes tooling instability. > >> > >> generators, es modules, destructing, let, fat arrows have caused > >> tremendous harm to tooling stability, which has made > >> frontend-development hell for everyone. > >> > >> > >> On 10/27/17, Jordan Harband wrote: > >> > aka "how it feels to learn"? > >> > > >> > A decent response: > >> > https://medium.com/front-end-hacking/how-it-feels-to-learn- > >> javascript-in-2017-a934b801fbe > >> > > >> > On Thu, Oct 26, 2017 at 3:38 PM, J Decker wrote: > >> > > >> >> (humor?) https://hackernoon.com/how-it-feels-to-learn-javascript-in- > >> 2016- > >> >> d3a717dd577f > >> >> > >> >> It all seemed so simple > >> >> > >> >> ___ > >> >> 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
