Re: Proposal: Syntax sugar for single exit and early exit functions.
I don't think we need to add any syntax sugar for the examples below.Answering with examples inline:17.11.2014, 03:07, “Biju” bijumaill...@gmail.com: I wish, I could write elegant two of the code pattern I use frequently.Patten 1.HTML button click event handler should always return false (ie, whenyou never want the submit action).So I always write.function someClickHandler(){ try {doStuff();doAnotherStuff();doYetAnotherStuff(); } catch(e){ } return false;} This is already good enough. If you want to handle exceptions, you have to add try..catch. Patten 2.I do like to code functions with early exit, likefunction 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();} If you do the same stuff after each function, some functional programming could help:function someValidationProcess() {
;[doStuff, doAnotherStuff, doYetAnotherStuff, doMoreStuff]
.forEach(function(fn) {
fn()
doCleanUp_1()
doCleanUp_2()
})
}
In this case doStuff would have to set a flag instead of condition_1() probably. Proposal:I wish there was some syntax sugar likefunction someClickHandler(){doStuff();doAnotherStuff();doYetAnotherStuff();} finally { return false;} Syntax sugar for try..catch? I don’t think we need one of those. function someValidationProcess(){doStuff();breakif(condition_1());doAnotherStuff();breakif(condition_2());doYetAnotherStuff();breakif(condition_3());doMoreStuff();} finally {doCleanUp_1();doCleanUp_2();} 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()
}
___
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.
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
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)
On Nov 16, 2014, at 11:08 PM, Tom Van Cutsem wrote:
2014-11-17 3:34 GMT+01:00 Frankie Bagnardi f.bagna...@gmail.com:
Consider when Array.isArray would be used. In my experience, checks to see
if something is an array are used for:
- deciding how to iterate it (for(;;) vs for..in, for example)
This is a good one. Here, again, a typical proxy-for-array would work as
intended, as the for(;;) loop just queries .length and properties named 0,
1, ... via standard [[Get]] access.
Can someone come up with a convincing example where a proxy-for-array would
*not* work as intended?
(convincing here means it doesn't involve a proxy that blatantly violates
the Array contract on purpose)
Probably not, because the Array.prototype methods are all carefully coded to
not have any internal slot or this identify dependencies.
But probing through the proxy as has been proposed is a terrible violation of
the MOP API boundary and isn't generalizable to other built-ins that are
dependent upon internal state. While a null handler proxy on a direct instance
of Array would work under that design, a comparable Map.isMap or
Promise.isPromise method would not. Rather than a one-off hack I think we
should use a new pattern that is generalizable:
Here is a proposal:
Array.isArray is redefined equivalently to:
```js
Array.isArray = function (obj) {
let constructor = obj.constructor;
If (typeof constructor != 'function') return false;
return !!constructor[Symbol.isArray];
}
```
and also
```js
Array[Symbol.isArray]] = true; //note, this is a constructor property, not an
Array.prototype property.
```
we also change Array.prototype.concat to do the above Array.isArray test
instead of using @@comcatSpreadable and change JSON.stringify to use this test
where it current checks for an exotic array object.
Then we have the following:
assert(Array.isArray( [ ] )); //just like ES5
assert( ! Array.isArray( Object.create(Array.prototype))); //just like ES5
assert (new class extends Array{}); //ES6 Array subclass instances answer true
unless the subclass over-rides the static @@isArray property
assert(new class extends Array {
constructor() {return {}};
}); // even if the subclass instance isn't an exotic array object (this is an
improvement over the current ES6 spec. which says that
//isArray answers false in this case
assert(new Proxy( [ ], { }); //because it's all done with property access, no
instance inspection required.
assert( ! new Int32Array(10)); //not array-like, just like ES5
However, I think we should experiment with giving %TypedArrau% is true valued
@@isArray property. I'm guessing that this change won't actually break
anything.
the above proposal completely decouples Array.isArray from exotic array object
checking or any other direct instance inspection. Everything works at the
property access level and so is (by default) transparent to proxies and
completely controllable at the ES cod level.
allen
___
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)
Allen Wirfs-Brock wrote:
```js
Array[Symbol.isArray]] = true; //note, this is a constructor
property, not an Array.prototype property.
Minomer, then -- how about Symbol.isArrayClass?
we also change Array.prototype.concat to do the above Array.isArray
test instead of using @@comcatSpreadable and change JSON.stringify to
use this test where it current checks for an exotic array object.
Then we have the following:
assert(Array.isArray( [ ] )); //just like ES5
assert( ! Array.isArray( Object.create(Array.prototype))); //just like ES5
How so? True:
js Array.isArray(Array.prototype)
true
js Array.isArray(Object.create(Array.prototype))
false
but constructor isn't shadowed:
js Array.prototype.constructor
function Array() {
[native code]
}
js Object.create(Array.prototype).constructor
function Array() {
[native code]
}
assert (new class extends Array{}); //ES6 Array subclass instances
answer true unless the subclass over-rides the static @@isArray property
assert(new class extends Array {
constructor() {return {}};
}); // even if the subclass instance isn't an exotic array object
(this is an improvement over the current ES6 spec. which says that
//isArray answers false in this case
assert(new Proxy( [ ], { }); //because it's all done with property
access, no instance inspection required.
(These want Array.isArray inside assert, of course.)
assert( ! new Int32Array(10)); //not array-like, just like ES5
However, I think we should experiment with giving %TypedArrau% is true
valued @@isArray property. I'm guessing that this change won't
actually break anything.
Probably ok.
the above proposal completely decouples Array.isArray from exotic
array object checking or any other direct instance inspection.
Everything works at the property access level and so is (by default)
transparent to proxies and completely controllable at the ES cod level.
Righteous goal!
/be
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Map: filter/map and more
Is this something what is ready for discussion on a meeting (in particular,
tomorrow's meeting)?
Regardless, whether the `map` and `set` will be directly on the
`Map.prototype` or on some generic `%CollectionPrototype%`, the user-level
API will stay the same, right? And will be used as:
```
myMap.map((v, k) = { ... });
```
I was just curious, is it already the time when it can be confirmed on a
meeting, that the API will likely be this (assuming we have `map.forEach`
already)? We'd like already to extend the `Map` and `Set` API (by extending
the ES6 base implementation) with several new methods, and start using them.
If this spec https://gist.github.com/DmitrySoshnikov/a218700746b2d7a7d2c8
is good enough to discuss it and can be confirmed, will it be a good time
on the following meeting? This PR for agenda wasn't merged for almost a
month: https://github.com/tc39/agendas/pull/53
If it can be confirmed already now, and no actual meeting discussion is
needed for this, I'm fine with this as well.
The only thing that may not confirm it, is using that new binding method
`::` operator and iter tools:
```
import {map} form 'iter-tools'
map::map(...);
```
But this as I understand is not even in early stage of a proposal (and
again, having dependency/correlation on `map.forEach` probably the `map`
and `filter` will nevertheless be used as just `map.map`).
P.S.: besides these two methods, maps and sets API is pretty basic at the
moment and doesn't have many every-day to use which are available in
other languages in these collections: like the most obvious intersect or
union operations for sets, etc. However, we can start with map and
filter yet ;)
Dmitry
On Wed, Oct 8, 2014 at 8:05 PM, Dmitry Soshnikov dmitry.soshni...@gmail.com
wrote:
On Wed, Oct 8, 2014 at 3:09 PM, Brendan Eich bren...@mozilla.org wrote:
Dmitry Soshnikov wrote:
The Collection protocol thus consists of at least .constructor,
@@iterator, .set. (Is there a better way to clone? Don't want a
new protocol where an old one will suffice!) This Collection
protocol would include Map and maplikes but leaves out Set, Array,
Object -- appropriately.
As long as it can be generic enough for `Map`, `Set`
Set methods include add, whereas Map has set. Set lacks a get method,
whereas Map of course has one. So not the same protocol.
I see, yeah, it's doable, and potentially they can be handled via abstract
operations with checking kind of a collection (`IsSet`, `IsMap`), and
setting needed entries (`AddEntry` would cover `set` for maps, and `add`
for Sets), and `GetEntry` would return needed thing since sets are just
backed by maps. However, this seems not a big win in terms of constant
runtime checks for this, and probably having a separate algorithms are
better (even if some parts are repeated).
If you want to have just an explicit protocol/interface for MapLikes and
SetLikes (i.e. with any explicit `set` method, and stuff which can be
implemented at user-level by any object), it's possible. Although, this
interface implementation can also be just replaced with sub-classing of the
`Map`, and the same algorithm works. It's just a difference b/w duck-typing
(the protocol, that any object may implement regardless its hierarchy), or
the inheritance. Will think about it, and maybe will come up with a spec.
Dmitry
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Map: filter/map and more
Dmitry Soshnikov wrote: Is this something what is ready for discussion on a meeting (in particular, tomorrow's meeting)? You put something on the agenda, cool. https://github.com/tc39/agendas/blob/master/2014/11.md /be ___ 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)
On Nov 17, 2014, at 11:06 AM, Brendan Eich wrote:
Allen Wirfs-Brock wrote:
```js
Array[Symbol.isArray]] = true; //note, this is a constructor property, not
an Array.prototype property.
Minomer, then -- how about Symbol.isArrayClass?
perhaps, I have a negative reaction to including the work class but can
probably live with it.
we also change Array.prototype.concat to do the above Array.isArray test
instead of using @@comcatSpreadable and change JSON.stringify to use this
test where it current checks for an exotic array object.
Then we have the following:
assert(Array.isArray( [ ] )); //just like ES5
assert( ! Array.isArray( Object.create(Array.prototype))); //just like ES5
How so? True:
js Array.isArray(Array.prototype)
true
js Array.isArray(Object.create(Array.prototype))
false
but constructor isn't shadowed:
js Array.prototype.constructor
function Array() {
[native code]
}
js Object.create(Array.prototype).constructor
function Array() {
[native code]
}
Shit, you're right. This is the hard case for legacy compat using this
technique.
I think I see a way to make this give the legacy answer, but I suspect I can't
make it give the same answer for
Array.isArray(new Proxy(Object.create(Array.prototype), { }));
May limiting the WTF=ness to that case isn't so bad.
assert (new class extends Array{}); //ES6 Array subclass instances answer
true unless the subclass over-rides the static @@isArray property
assert(new class extends Array {
constructor() {return {}};
}); // even if the subclass instance isn't an exotic array object (this is
an improvement over the current ES6 spec. which says that
//isArray answers false in this case
assert(new Proxy( [ ], { }); //because it's all done with property access,
no instance inspection required.
(These want Array.isArray inside assert, of course.)
of course
assert( ! new Int32Array(10)); //not array-like, just like ES5
However, I think we should experiment with giving %TypedArrau% is true
valued @@isArray property. I'm guessing that this change won't actually
break anything.
Probably ok.
the above proposal completely decouples Array.isArray from exotic array
object checking or any other direct instance inspection. Everything works at
the property access level and so is (by default) transparent to proxies and
completely controllable at the ES cod level.
Righteous goal!
/be
___
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)
On Nov 17, 2014, at 2:30 PM, Allen Wirfs-Brock wrote:
On Nov 17, 2014, at 11:06 AM, Brendan Eich wrote:
Allen Wirfs-Brock wrote:
```js
Array[Symbol.isArray]] = true; //note, this is a constructor property, not
an Array.prototype property.
Minomer, then -- how about Symbol.isArrayClass?
perhaps, I have a negative reaction to including the work class but can
probably live with it.
we also change Array.prototype.concat to do the above Array.isArray test
instead of using @@comcatSpreadable and change JSON.stringify to use this
test where it current checks for an exotic array object.
Then we have the following:
assert(Array.isArray( [ ] )); //just like ES5
assert( ! Array.isArray( Object.create(Array.prototype))); //just like ES5
How so? True:
js Array.isArray(Array.prototype)
true
js Array.isArray(Object.create(Array.prototype))
false
but constructor isn't shadowed:
js Array.prototype.constructor
function Array() {
[native code]
}
js Object.create(Array.prototype).constructor
function Array() {
[native code]
}
Shit, you're right. This is the hard case for legacy compat using this
technique.
I think I see a way to make this give the legacy answer, but I suspect I
can't make it give the same answer for
Array.isArray(new Proxy(Object.create(Array.prototype), { }));
May limiting the WTF=ness to that case isn't so bad.
OK, this should deal with the Object.create(Array.prototype) case
Array.isArray = function isArray(obj) {
let constructor = obj.constructor;
If (typeof constructor != 'function') return false;
let construictorIs be Object.getOwnPropertyDescript(constructor,isArray);
if (constructorIs) {
//the constructor has an isArray property, so we'll assume it is a
built-in Array constructor
if (isOrdinaryObject(obj)) return false; //The
Object.create(Array.prototype) legacy compat. case.
if (isProxy(obj)) return isArray(getProxyTarget(obj));
//Array.isArray(new Proxy(Object.create(Array.prototype), {}))
//I'm not sure that the above line is really a compat. issue. I'd prefer
to leave it out.
}
return !!constructor[Symbol.isArray];
}
It takes a little hackery to deal with the legacy
Object.create(Array.prototype) cases but for ES6 subclasses and non-subclasses
such as typed arrays it doesn't perform any exotic instance sniffing.
Allen
___
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)
Allen Wirfs-Brock wrote:
if (isProxy(obj)) return isArray(getProxyTarget(obj));
//Array.isArray(new Proxy(Object.create(Array.prototype), {}))
//I'm not sure that the above line is really a compat. issue. I'd
prefer to leave it out.
Please do -- it contradicts the righteous goal.
/be
___
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.
On 17 November 2014 11:29, Alex Kocharin a...@kocharin.ru wrote:
If you do the same stuff after each function, some functional programming
could help:
function someValidationProcess() {
;[doStuff, doAnotherStuff, doYetAnotherStuff, doMoreStuff]
.forEach(function(fn) {
fn()
doCleanUp_1()
doCleanUp_2()
})
}
In this case doStuff would have to set a flag instead of condition_1()
probably.
Just want to add, usually in corporate world a .Net or Java developer
is who code JavaScript. The code above may be little complex for them.
___
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)
2014-11-17 18:30 GMT+01:00 Allen Wirfs-Brock al...@wirfs-brock.com: But probing through the proxy as has been proposed is a terrible violation of the MOP API boundary and isn't generalizable to other built-ins that are dependent upon internal state. While a null handler proxy on a direct instance of Array would work under that design, a comparable Map.isMap or Promise.isPromise method would not. Rather than a one-off hack I think we should use a new pattern that is generalizable: If we can find consensus on this much more general pattern of type-testing by using a symbol on the constructor, I'm all for it. +1! I also think we don't want to special-case Proxies in the proposed type-testing algorithm. That said, if we cannot come to a consensus on this more generic form of type-testing, I would still defend the position that Array.isArray merits an exception (compared to Map.isMap/Promise.isPromise etc.) *precisely because* Arrays were carefully defined not to depend on any special instance state. In this scenario, repurposing the @@isConcatSpreadable symbol seems like the most obvious thing to do (it currently feels terribly ad-hoc, making it something more generic such as @@isArrayLike makes more sense to me) Cheers, Tom ___ 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.
On 11/16/14, Biju bijumaill...@gmail.com wrote:
[...]
Proposal:
I wish there was some syntax sugar like
function someClickHandler(){
doStuff();
doAnotherStuff();
doYetAnotherStuff();
} finally {
return false;
}
function rf() {
try {
throw-an-error;
} finally {
return false;
}
}
rf(); // false
--
Garrett
@xkit
ChordCycles.com
garretts.github.io
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
