Allowing super to use EvaluateConstruct, or "How do I inherit from Date?"
Despite separating out @@create into a property of functions, which allows allocation and setting of BuiltinBrand for subclasses, this still leaves inheriting from most builtins just short of possible because they are "construct sensitive". The new ES6 classes like Map, Set, WeakMap, and typed arrays have been carefully designed so the constructor initializes `this`. But this still leaves most of the existing builtins un-subclassable. I know there's a strawman that addresses this, and many of the recent changes to the ES6 spec have been moving toward making this possible, but I don't recall seeing commentary on a planned solution for this. It seems like the last hurdle to actually making this work is simply making it possible for `super` to just "forward" to EvaluateCall or EvaluateConstruct depending on which of them invoked the function that the super call was in. Is this solution possible for ES6? Or maybe there's another plan in the works to address this? Or is this something that can be looked for in harmony (which I presume now refers to es-after 6/es7)? ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Enforcing arity?
On Sunday, January 6, 2013, Axel Rauschmayer wrote:
> What is the simplest way of enforcing an arity in ES6? Doesn’t it involve
> arguments?
>
> function add(x, y) {
> if (arguments.length !== 2) throw ...
> }
>
> To avoid `argument`, one could:
> - ensure a maximum arity by adding a ...rest parameter and checking that
> its length is 0.
>
I can't find the thread, but a similar question was asked sometime in the
last 6 months (I think??) and this was the answer that was ultimately
agreed on as the best way to check arity length.
- ensure a minimum arity, by giving y a default value and checking for it.
>
Explicit undefined arguments, intentional or not, would trigger the default
value.
Rick
>
> Would fail-fast destructuring work?
>
> function add(...args) {
> let [x,y] = args;
> }
>
> --
> Dr. Axel Rauschmayer
> a...@rauschma.de
>
> home: rauschma.de
> twitter: twitter.com/rauschma
> blog: 2ality.com
>
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: 10 biggest JS pitfalls
> Note that == does not respect truthiness or falsiness: > > > 2 == true > false > > 2 == false > false > > > '2' == true > false > > '2' == false > false > > None of these (above) abstract comparison operations represents "truthy" or > "falsy" behaviour. > > 0 == false; > // true > 11.9.3.7 converts to 0==0 > > > "" == false; > // true > 11.9.3.7 converts to ""==0 > 11.9.3.5 converts to 0==0 > > > 1 == true; > // true > 11.9.3.7 converts to 1==1 > > > "" becomes +0 per 9.3.1 > +0 becomes false per 9.2 > true becomes 1 per 9.3 table 12 > > > The unary logical NOT ! also converts with ToBoolean. > > 2==true is just the number two compared with the Boolean true, which aren't > equal in value or type and have no criteria for conversion. I am aware (2==true converts to 2==1). But I was surprised when I first found out. The above was slightly off-topic, because I misunderstood what trick Andrea was referring to. -- Dr. Axel Rauschmayer a...@rauschma.de home: rauschma.de twitter: twitter.com/rauschma blog: 2ality.com ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
10 biggest JS pitfalls
On Sunday, January 6, 2013, Axel Rauschmayer wrote: > > Exactly Brendan, I could not agree more and this is my No. 1 pitfall > about JS: developers often not doing real work complaining about stuff that > developers doing real work don't even care about or never ever had to worry > about. > > I don’t follow. Who are these people not doing “real work”? And I don’t > think discussing the language qualifies as complaining. > > > In any case they can learn and understand the feature/problem using the > feature when needed, avoiding its weakness when necessary. > > > > About falsy and truthy, null and undefined, who cares ... seriously, and > to be honest, that's not a pitfall, is rather a feature when needed as it > is for all other scripting languages as long as you know what you are doing > ... and no programming language will save you if you don't know what you > are doing and it's your duty, as developer, to understand the language you > are using if that's your job. > > “Warts” is probably a better term than “pitfalls”. > > > Again, about falsy ... if I see a glass empty, it does not mean I used a > microscope to understand no water is left in the whole glass surface ... I > just consider that empty and I add water on top. > > > > Engineers have the tendency to over complicate even simple tasks as the > one I've just described ... what is the benefit? What is the result? That > the day falsy values in JS will disappear libraries authors will implement > an isFalsy(value) function/method and use it 90% of the time regretting the > trick with == disappeared ... isn't it ;-) > > What is the trick with ==? Note that == does not respect truthiness or > falsiness: > > > 2 == true > false > > 2 == false > false > > > '2' == true > false > > '2' == false > false None of these (above) abstract comparison operations represents "truthy" or "falsy" behaviour. 0 == false; // true 11.9.3.7 converts to 0==0 "" == false; // true 11.9.3.7 converts to ""==0 11.9.3.5 converts to 0==0 1 == true; // true 11.9.3.7 converts to 1==1 "" becomes +0 per 9.3.1 +0 becomes false per 9.2 true becomes 1 per 9.3 table 12 The unary logical NOT ! also converts with ToBoolean. 2==true is just the number two compared with the Boolean true, which aren't equal in value or type and have no criteria for conversion. Rick > > > -- > Dr. Axel Rauschmayer > a...@rauschma.de > > home: rauschma.de > twitter: twitter.com/rauschma > blog: 2ality.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
Re: Enforcing arity?
Axel Rauschmayer wrote:
What is the simplest way of enforcing an arity in ES6? Doesn’t it
involve arguments?
function add(x, y) {
if (arguments.length !== 2) throw ...
}
To avoid `argument`, one could:
- ensure a maximum arity by adding a ...rest parameter and checking that
its length is 0.
- ensure a minimum arity, by giving y a default value and checking for it.
Would fail-fast destructuring work?
function add(...args) {
let [x,y] = args;
}
And it this would be possible, it could be in the signature:
function add(...[x,y,opt?]) {
}
--
Dr. Axel Rauschmayer
a...@rauschma.de
Herby
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Enforcing arity?
What is the simplest way of enforcing an arity in ES6? Doesn’t it involve
arguments?
function add(x, y) {
if (arguments.length !== 2) throw ...
}
To avoid `argument`, one could:
- ensure a maximum arity by adding a ...rest parameter and checking that its
length is 0.
- ensure a minimum arity, by giving y a default value and checking for it.
Would fail-fast destructuring work?
function add(...args) {
let [x,y] = args;
}
--
Dr. Axel Rauschmayer
a...@rauschma.de
home: rauschma.de
twitter: twitter.com/rauschma
blog: 2ality.com
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: fail-fast object destructuring (don't add more slop to sloppy mode)
Kevin Smith wrote:
Would we? This is something a little different than "irrefutable
property get". Thinking...
Notice that, strictly speaking, we don't need an "irrefutable object"
operation:
let v = ?o.p;
// is equivalent to:
let v = {o}.?o.p;
The allocation in "{o}" can be statically optimized away.
The same goes for the pattern language:
let ?{ p: v } = o;
// is equivalent to:
let { ?o: { p: v } } = {o};
Sure, but that's crying out for a shorter form that avoids repeating o.
Note also that in the expression language, |o| might be a longer
expression (even, gasp, with embedded effects) that you would not want
to repeat.
Whatever we do for existential operators, destructuring in ES6 with
refutable-by-default patterns wants something at all levels, including
outermost -- or so I argue.
/be
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: fail-fast object destructuring (don't add more slop to sloppy mode)
Kevin Smith wrote:
I raised this problem-case, so I want to point out that we could
take other courses:
* Reckon that labels are rare and this won't bite, so let it
stand, just as
a = b
(c)
is a hazard today -- and one that bites much more.
* Don't allow suffix-? to be followed by a newline.
Leaving aside ASI for a moment, there are other issues:
let v = obj?+(0+1+2+3+4+5+6+7+8+9+...+n):null;
We don't know whether this is a conditional expression or not until we
get to the ":" an arbitrary distance away from the "?".
Yes, this is a good point if obj? could be an expression on the left of
binary +. The same problem arises with - / [ and ( of course -- just as
with lack-of-ASI.
We might be able to use another cover grammar approach here, but is it
worth it?
We'd rather use a lookahead restriction forbidding the token after ?
from being in {+,-,/,[,(} -- and possibly from being a LineTerminator,
although that seems silly to me on reflection.
Apart from deviating from the cowpath (CoffeeScript), prefix-? is
equivalent to suffix-? as I argued in reply to Herby. We'd want to
support
let ?{p: v} = o;
let v = ?o.p;
to handle the case of undefined or null 'o', of course, in which
case v would be initialized to undefined.
Would we? This is something a little different than "irrefutable
property get". Thinking...
The suffix-? operator works on identifier expressions too. Those happen
to irrefutably throw just fine (throw ReferenceError) in JS, unlike
MemberExpressions such as foo.bar where !('bar' in foo).
/be
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Rationale for why ECMAScript converts primitive values to numbers in == operator comparisons when one is boolean
Brendan Eich wrote:
The bias toward comparing strings as numbers if either operand is a
number or a boolean stems from the HTTP header and numeric-string HTML
form field use-cases. Not good reasons, again, but that's how JS
"works" :-|.
One more note: it could be argued that narrowing from string to number
would be ok (as in, useful most of the time, and not unsafe) if any
non-numeric, non-empty string-to-number implicit conversion attempt
threw an exception.
Here's where another path-dependent bias in JS's design bit: no
try/catch in JS1 or any ECMA-262 standard till ES3.
The lack of exception handling also meant undefined is imputed for
missing obj.foo property get where obj has no such property. That is
still biting back, perhaps as much as or more than implicit conversions
bite ==. It is also the basis of web JS's winning "object detection"
pattern, which fairly beats all other versioning schemes I've seen,
especially a-priori ones based on explicit numbering and opt-in.
If only I'd taken the time to add an existential operator for object
detection, so one could write
function emulateRequestAnimationFrame(...) {...}
if (!window.requestAnimationFrame?)
window.requestAnimationFrame = emulateRequestAnimationFrame;
IOW, if only I'd made window.noSuchProperty throw but
window.noSuchProperty? evaluate to truthy or false (details still TBD,
see the "fail-fast object destructuring" thread revival, the Nil idea).
/be
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Rationale for why ECMAScript converts primitive values to numbers in == operator comparisons when one is boolean
Brendan Eich wrote: If we fixed this botch, we'd still have: 0 == "0" true == "1" false == "0" Sorry, make that: 0 == "0" 1 == "1" true != "1" false != "0" Also: false != "" Per my calling the preference for number over string conversion a botch, we would not have true == "1" or false == "0", because that narrows from string to number. It's true the narrowing loses no bits, and one can widen 0 back to "0" and 1 back to "1", but I meant to illustrate what removing all number-over-string bias from the implicit conversion spec for == would do. Would such a change break a lot of code on the web? I'd bet large sums it would. But we would also have what your example wants: true == "true" This part stands. /be ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Rationale for why ECMAScript converts primitive values to numbers in == operator comparisons when one is boolean
Raymond Plante wrote:
Just curious to find out what the motivation for converting both
values of an == operation to integers if one is an integer or a boolean.
This situation allows for:
if ("true"){} // to evaluate to true
if("true" == true){} // to evaluate to false as it's really
checking if( NaN == 1){}
Consider Perl:
$ perl -e 'print 0 == "true";'
1
Ok, poor rationale -- but I created JS in May 1995, in the shadow of
AWK, Perl 4, Python 1.2 (IIRC), TCL.
I should have paid more attention to AWK than Perl, given
$ awk 'END {print(0 == "0")}'
1D
$ awk 'END {print(0 == "")}'
0D
In some ways, JS's == operator splits the difference between Perl (where
non-numeric strings such as "true" convert to 0) and AWK (where only "0"
converts to 0) by converting to NaN. That way, at least, we have
js> 0 == ""
true
js> 0 == "true"
false
But the full truth is not that I was carefully emulating other
languages. Rather, some Netscapers working to embed JS (then "Mocha") in
a PHP-like server (LiveWire) wanted sloppy conversions, so programmers
could match HTTP header strings (server side) or HTML form fields
(client side) against, e.g., 404 and the like, without explicit coercion
by the programmer.
But it was the 90s, I was in a tearing hurry, these ex-Borland
Netscapers were persistent. So, as I said at Strange Loop last year
(http://www.infoq.com/presentations/State-JavaScript), "I was an idiot!
I gave them what they wanted!"
Implicit conversions are my biggest regret in JS's rushed design, bar
none. Even including 'with'!
Does anyone know the exact reason the choice was made not to convert
to boolean any value compared against a boolean in with the == operator?
The general idea is the narrower type should widen. Thus, true == 1
follows by projecting boolean {false, true} onto {0, 1}, as in C++.
But why not widen true to string, since the other operand in your
example is "true"? Good question. The bias toward comparing strings as
numbers if either operand is a number or a boolean stems from the HTTP
header and numeric-string HTML form field use-cases. Not good reasons,
again, but that's how JS "works" :-|.
You can see this in the ECMA-262 Edition 5.1 spec, 11.9.3 The Abstract
Equality Comparison Algorithm, steps 6 & 7 (read in light of steps 4 & 5):
4. If Type(x) is Number and Type(y) is String, return the result of the
comparison x == ToNumber(y).
5. If Type(x) is String and Type(y) is Number, return the result of the
comparison ToNumber(x) == y.
6. If Type(x) is Boolean, return the result of the comparison
ToNumber(x) == y.
7. If Type(y) is Boolean, return the result of the comparison x ==
ToNumber(y).
This is all in a big "else clause where Type(x) and Type(y) for x == y
are not the same.
Sorry there's no pearl (sic) of wisdom here. In addition to implicit
conversions, == and != do not widen operands directly (no intermediate
conversions) to the narrowest width that can hold the other operand
without data loss. This narrowing string to number is just a botch.
If we fixed this botch, we'd still have:
0 == "0"
true == "1"
false == "0"
But we would also have what your example wants:
true == "true"
Some take this botch, on top of any implicit conversion under the hood,
as another reason to use === and !== always (because they never
convert), and to utterly shun == and !=. Others disagree (especially
when testing x == null, a one-operator way to test x === null || x ===
undefined).
Since the web grows mostly-compatibly until very old forms die off,
we're stuck with == and !=, so I say it pays to learn what the sloppy
equality operators do. Having done that, it seems to me one may use them
where they win: when you know the operands are same-type, e.g.
typeof x == "function", etc.
x == null
And otherwise, use === and !==.
/be
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Property descriptor normalization (Was: General comments response (was Re: ES6 Rev13 Review: MOP-refactoring, symbols, proxies, Reflect module))
On Jan 5, 2013, at 12:24 AM, Tom Van Cutsem wrote: > 2013/1/4 Allen Wirfs-Brock > > ... > > You're concerned about the nature of the descriptor object returned from the > getOwnProertyDescriptor trap. In particular, you want to have something > stable enough that you can reason about it and reliably enforce whatever > attribute invariants we may have. > > I want to avoid cloning, extensive validation, or normalization to > data/accessor properties of the object returned by the trap. > > As a middle ground that we can build upon I suggest we start with the > following enforced invariants for the gOPD trap: > > 1) The object returned must be an ordinary object > 2) If the object has value,get,set, writable, enumerable, or configurable > properties, then those property must be data properties. > > These rules indeed take away most of my fear of breaking existing code by > guaranteeing the stability of "desc.configurable" etc. > > I wonder though how easy it is to verify part 2) since descriptor objects may > inherit these properties. Since there is no [[GetProperty]] anymore, one > would need to explicitly walk the proto-chain in search for the descriptor. > This makes the verification more expensive again. It probably also means that > property descriptors may not inherit from proxies. If you think it is important, I'd be willing to go a step further and say that such properties must be own properties. It takes away some flexibility from handlers but I'm willing to give it up. For reasoning purposes you probably you wouldn't want to allow exotic objects (including Proxies) on the prototype chain anyway. Because Proxy [[GetOwnProperty]] normalized to a PD record it already has to look at these properties so verifying #2 for own properties would probably add very little extra cost. > > In addition, handlers should adhere to the following unenforced rules: > > a) properties of the descriptor object should be configurable and writable > (if a data property) > b) a property descriptor should contain all information that would be > necessary to create the property it describes, if that property did not > already exist. > c) If a property descriptor object contains either a "value" or "writable" > property it should not also contain a "get" or "set" property. > > Failure to adhere to the unenforced rules may lead to unexpected client code > behavior but does will not threaten the integrity or stability of the ES > execution environment. > > What do you think? Can we start with the above as a baseline? > > It's a start, but I'm still uncomfortable because of potential aliasing > issues: if the returned descriptor object is not a copy, then a proxy handler > may hold onto a reference to the returned descriptor object. This means it > can still update the (mutable) descriptor after having returned it from the > trap. The aliasing in combination with the mutability may still trip up > clients unexpectedly. Only if the client makes a call that gives control back to the handler (or its cohorts) and, in general, all bets are off once you call into untrusted code. Allen ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Rationale for why ECMAScript converts primitive values to numbers in == operator comparisons when one is boolean
Just curious to find out what the motivation for converting both values of
an == operation to integers if one is an integer or a boolean.
This situation allows for:
if ("true"){} // to evaluate to true
if("true" == true){} // to evaluate to false as it's really checking if(
NaN == 1){}
Does anyone know the exact reason the choice was made not to convert to
boolean any value compared against a boolean in with the == operator?
Regards,
Raymond J. Plante
StackOverflow: http://stackoverflow.com/users/722263/ray
LinkedIn: http://www.linkedin.com/in/raymondjplante
Blog: http://www.kineticklink.com
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: 10 biggest JS pitfalls
>> >> On Sun, Jan 6, 2013 at 5:06 AM, Axel Rauschmayer wrote: >>> >>> This is not about pointing out how bad JavaScript is, it is about >>> collecting things that confuse people who are new to the language. They >>> help those people to learn what you already know. Many people really hate >>> JavaScript. Some of those, we’ll never convert, they’d rather program Java >>> than JavaScript (as you point out above). But some do cite valid WTFs. Some >>> of those WTFs even get you if you know the language well (e.g. `this` in >>> non-method functions). Thankfully, ES6 will fix many of those. It’ll prove >>> the haters wrong who say that JavaScript is beyond fixing. >>> Well, with this explanation, I understand better the sense of your three first "biggest pitfalls": They are just things that confuse people coming from some other definite programming language and accustomed to different semantics. You probably won't say that the OO model of Java (for example) is a pitfall (even less a "biggest" one), even if it may confuse people new to OO-programming; rather it is a handful feature that works well. In the same vein, the notion of truthy/falsy, the sloppy == operator, and the distinction between null and undefined, do not deserve to be called "pitfalls" or "warts", for they are indeed positively useful features (and much easier ones than classes and objects) that work without problem once you have correctly learned them. (BTW, "Some of those, we’ll never convert, they’d rather program Java than JavaScript." I bet that those people don't know how much they lose by not having proper first-class functions ;-) —Claude___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Reduce context parameter
Mostly out of curiosity; why do Array#reduce and reduceRight have no context parameter? - peter ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: 10 biggest JS pitfalls
[cc-ing es-discuss again] Yes. I like the idea of JS(L|H)int as a teacher for newcomers! On Jan 6, 2013, at 15:52 , Andrea Giammarchi wrote: > I think for your latter point and about haters, JSLint can help there. Put in > this way ... I hate JSLint :D > > > On Sun, Jan 6, 2013 at 5:06 AM, Axel Rauschmayer wrote: >> Do not think what you learned at University about Java is the way every >> programming language should be do not think other programming/scripting >> languages are inferior because of your inflexible, indoctrinated knowledge >> about programming, just learn something more, read specs, those are small >> for what the language offer in JS case, and stop moaning about null and >> undefined, falsy, and all those script thing stat made scripting >> historically easier and often more productive than strict programming >> languages. >> >> The "you" I have used here is not about you .. you know these things, so why >> even bothering calling them pitfalls ... pitfalls are those nobody can >> understand, your 10 points are my breakfast, if you don't mind passing the >> metaphor ... >> >> As summary, in my opinion, there's no need to write top 10 here: these are >> pointless, completely subjective, and **always** available, no matter which >> one is the topic. > > This is not about pointing out how bad JavaScript is, it is about collecting > things that confuse people who are new to the language. They help those > people to learn what you already know. Many people really hate JavaScript. > Some of those, we’ll never convert, they’d rather program Java than > JavaScript (as you point out above). But some do cite valid WTFs. Some of > those WTFs even get you if you know the language well (e.g. `this` in > non-method functions). Thankfully, ES6 will fix many of those. It’ll prove > the haters wrong who say that JavaScript is beyond fixing. > >> These, are not what we need ... Object.observe idea/mechanism/possibility >> is, the fat null is == undefined is not stopping anyone, and never did, from >> creating amazing stuff with the Web or, lately, the server. > > Those are complementary issues! We need to both make the core of JavaScript > simpler and give it functionality such as Object.observe(). Both is > happening, so I’m not worried. > > -- > Dr. Axel Rauschmayer > a...@rauschma.de > > home: rauschma.de > twitter: twitter.com/rauschma > blog: 2ality.com > > -- Dr. Axel Rauschmayer a...@rauschma.de home: rauschma.de twitter: twitter.com/rauschma blog: 2ality.com ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: fail-fast object destructuring (don't add more slop to sloppy mode)
>
> Would we? This is something a little different than "irrefutable property
> get". Thinking...
>
>
Notice that, strictly speaking, we don't need an "irrefutable object"
operation:
let v = ?o.p;
// is equivalent to:
let v = {o}.?o.p;
The allocation in "{o}" can be statically optimized away.
The same goes for the pattern language:
let ?{ p: v } = o;
// is equivalent to:
let { ?o: { p: v } } = {o};
{ Kevin }
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: fail-fast object destructuring (don't add more slop to sloppy mode)
Kevin Smith wrote:
Is it bad to specify that unless it is at the end of (sub)Expression
or before dot, '?' is treated as first ? in ?: ? Then you have to
explicitly parenthesize it and that's all.
How do you specify "end of expression", though? You have to consider
ASI here as well. Is the complexity you suggest worth it?
ASI here as well :-/ hm, yes.
It is complicated.
The only solution I see now is abandon deatiled grammar solution, move
to higher point of view, treat ? always as ?:, and if the next thing you
see is a dot or end of subexpression (by any means), make it
"existential ?".
It is probably what you are saying by "not worth the complexity".
{ Kevin }
Herby
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: fail-fast object destructuring (don't add more slop to sloppy mode)
>
> Is it bad to specify that unless it is at the end of (sub)Expression or
> before dot, '?' is treated as first ? in ?: ? Then you have to explicitly
> parenthesize it and that's all.
>
How do you specify "end of expression", though? You have to consider ASI
here as well. Is the complexity you suggest worth it?
{ Kevin }
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: fail-fast object destructuring (don't add more slop to sloppy mode)
Kevin Smith wrote:
I raised this problem-case, so I want to point out that we could
take other courses:
* Reckon that labels are rare and this won't bite, so let it stand,
just as
a = b
(c)
is a hazard today -- and one that bites much more.
* Don't allow suffix-? to be followed by a newline.
Leaving aside ASI for a moment, there are other issues:
let v = obj?+(0+1+2+3+4+5+6+7+8+9+...+n):null;
Is it bad to specify that unless it is at the end of (sub)Expression or
before dot, '?' is treated as first ? in ?: ? Then you have to
explicitly parenthesize it and that's all.
We don't know whether this is a conditional expression or not until we
get to the ":" an arbitrary distance away from the "?". We might be
able to use another cover grammar approach here, but is it worth it?
{ Kevin }
Herby
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: fail-fast object destructuring (don't add more slop to sloppy mode)
> I raised this problem-case, so I want to point out that we could take
> other courses:
>
> * Reckon that labels are rare and this won't bite, so let it stand, just as
>
> a = b
> (c)
>
> is a hazard today -- and one that bites much more.
>
> * Don't allow suffix-? to be followed by a newline.
Leaving aside ASI for a moment, there are other issues:
let v = obj?+(0+1+2+3+4+5+6+7+8+9+...+n):null;
We don't know whether this is a conditional expression or not until we get
to the ":" an arbitrary distance away from the "?". We might be able to
use another cover grammar approach here, but is it worth it?
>
> You must have meant (2).
>
Yep!
>
> Apart from deviating from the cowpath (CoffeeScript), prefix-? is
> equivalent to suffix-? as I argued in reply to Herby. We'd want to support
>
> let ?{p: v} = o;
> let v = ?o.p;
>
> to handle the case of undefined or null 'o', of course, in which case v
> would be initialized to undefined.
>
Would we? This is something a little different than "irrefutable property
get". Thinking...
{ Kevin }
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: 10 biggest JS pitfalls
Axel, it wasn't referred to you explicitly, rather to all those developers still wining about this == null problem which has never been in my daily, real work, code. choose one: value === undefined || value === null in a language where undefined and null are different and for a good reason (not defined is different from defined as null) that one, against value == null who wins ... and why, if specs say latter one is equivalent? because! Same is for falsy, I don't even want to start talking about it ... you write JavaScript, learn these two or three things that could be mistaken, learn how take advantage and avoid mistaken them when needed. Do not think what you learned at University about Java is the way every programming language should be do not think other programming/scripting languages are inferior because of your inflexible, indoctrinated knowledge about programming, just learn something more, read specs, those are small for what the language offer in JS case, and stop moaning about null and undefined, falsy, and all those script thing stat made scripting historically easier and often more productive than strict programming languages. The "you" I have used here is not about you .. you know these things, so why even bothering calling them pitfalls ... pitfalls are those nobody can understand, your 10 points are my breakfast, if you don't mind passing the metaphor ... As summary, in my opinion, there's no need to write top 10 here: these are pointless, completely subjective, and **always** available, no matter which one is the topic. These, are not what we need ... Object.observe idea/mechanism/possibility is, the fat null is == undefined is not stopping anyone, and never did, from creating amazing stuff with the Web or, lately, the server. Just my 2 cents, don't take it personal, please! br On Sun, Jan 6, 2013 at 12:14 AM, Axel Rauschmayer wrote: > > Exactly Brendan, I could not agree more and this is my No. 1 pitfall > about JS: developers often not doing real work complaining about stuff that > developers doing real work don't even care about or never ever had to worry > about. > > I don’t follow. Who are these people not doing “real work”? And I don’t > think discussing the language qualifies as complaining. > > > In any case they can learn and understand the feature/problem using the > feature when needed, avoiding its weakness when necessary. > > > > About falsy and truthy, null and undefined, who cares ... seriously, and > to be honest, that's not a pitfall, is rather a feature when needed as it > is for all other scripting languages as long as you know what you are doing > ... and no programming language will save you if you don't know what you > are doing and it's your duty, as developer, to understand the language you > are using if that's your job. > > “Warts” is probably a better term than “pitfalls”. > > > Again, about falsy ... if I see a glass empty, it does not mean I used a > microscope to understand no water is left in the whole glass surface ... I > just consider that empty and I add water on top. > > > > Engineers have the tendency to over complicate even simple tasks as the > one I've just described ... what is the benefit? What is the result? That > the day falsy values in JS will disappear libraries authors will implement > an isFalsy(value) function/method and use it 90% of the time regretting the > trick with == disappeared ... isn't it ;-) > > What is the trick with ==? Note that == does not respect truthiness or > falsiness: > > > 2 == true > false > > 2 == false > false > > > '2' == true > false > > '2' == false > false > > > -- > Dr. Axel Rauschmayer > a...@rauschma.de > > home: rauschma.de > twitter: twitter.com/rauschma > blog: 2ality.com > > ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: 10 biggest JS pitfalls
> Exactly Brendan, I could not agree more and this is my No. 1 pitfall about > JS: developers often not doing real work complaining about stuff that > developers doing real work don't even care about or never ever had to worry > about. I don’t follow. Who are these people not doing “real work”? And I don’t think discussing the language qualifies as complaining. > In any case they can learn and understand the feature/problem using the > feature when needed, avoiding its weakness when necessary. > > About falsy and truthy, null and undefined, who cares ... seriously, and to > be honest, that's not a pitfall, is rather a feature when needed as it is for > all other scripting languages as long as you know what you are doing ... and > no programming language will save you if you don't know what you are doing > and it's your duty, as developer, to understand the language you are using if > that's your job. “Warts” is probably a better term than “pitfalls”. > Again, about falsy ... if I see a glass empty, it does not mean I used a > microscope to understand no water is left in the whole glass surface ... I > just consider that empty and I add water on top. > > Engineers have the tendency to over complicate even simple tasks as the one > I've just described ... what is the benefit? What is the result? That the day > falsy values in JS will disappear libraries authors will implement an > isFalsy(value) function/method and use it 90% of the time regretting the > trick with == disappeared ... isn't it ;-) What is the trick with ==? Note that == does not respect truthiness or falsiness: > 2 == true false > 2 == false false > '2' == true false > '2' == false false -- Dr. Axel Rauschmayer a...@rauschma.de home: rauschma.de twitter: twitter.com/rauschma blog: 2ality.com ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
