In an LR(1) grammar, if vs. if-else or ? vs. ?: is a shift-reduce conflict
(to use yacc terms). It is an ambiguity. It can be disambiguated, but
please do not confuse disambiguation via shifting with "no *real*
ambiguity".
My point is it IS disambiguated by the definition of operator precedence.
The adding of an optional nature to the : portion of ?: wouldn't change
that, as the expression would still hinge on the same definition of operator
precedence. So it doesn't really introduce additional ambiguity (either
visual or processing-wise), that isn't already there for ?: usage. It just
piggybacks on that same operator-precedence-disambiguity which is long-held
in JavaScript. In fact, based on the definition I'm putting forth, I don't
think it requires any (or hardly any) additional "rules" for operator
precedence or disambiguation.
I'm sorry, I'm lost by this statement. I don't understand on what basis
you conclude that I just argued against the very thing I'm asking for.
Can you elaborate at all?
You made an ad-hoc argument for a ? b : undefined but want to write that
as a ? b. The latter is not obviously the same (Dmitry pointed out the
potential for confusion with ??, which has a very different result).
OK, fair enough, I can see how some confusion is possible, IF the ??
operator is also added. But I am not convinced that possible future
confusion is, alone, enough for invalidation of an idea. I can name a number
of things coming down the pike for ES next's that are, at first, a little
confusing, and take some getting used to. Their value to the language, and
to syntactic sugaring, withstands the initial confusion.
It's also not obviously a good non-hard case to burn into the grammar.
What is non-hard about saying that, in the processing of any ?: expression,
if the ? is present but the : is not found where it is expected, then the :
is implied and is always `: undefined` (or `: void 0`, if you prefer)?
Perhaps I'm missing it, but I really don't see how it's any harder than that
alone.
How is
doX = (someX > 0 && someX < 10) ? someX
more suggestive of a "boolean" value than is
doX = (someX > 0 && someX < 10) ? someX : undefined
The name "doX" connotes boolean.
OK, so your complaint is about the bad name I gave that variable. Fine.
Agreed. "do" was a bad word for a non-boolean. s/do(X|Y)/coord$1. Variables
names in examples aside, the point of the example (the operator usage)
should be clear. Not sure why it isn't?
I'm not sure if you're arguing against:
a) the pattern of having an `undefined` value in a variable when "unset",
that otherwise stores numbers when it's "set"; OR
b) the implied `: undefined`
Both, (b) because of (a). I was explicit about this, there's no confusion.
There is still confusion on my part, because I honestly don't see how (b)
necessarily and unequivocally follows from (a). I can clearly see that you
want to connect them, but I don't see why they have to be. (see below).
No, people do not risk converting undefined to NaN (to 0). It's true that
var hoisting means undefined inhabits the type of all vars, but unless yo
use an uninitialized var, that's not an issue.
There's many other ways that variables get to `undefined` besides them not
yet being initialized. For instance:
1. `delete opts.coordX`
2. unsetting variables so the value is GC'd.
3. setting variables to `undefined` (or `void 0`) to prevent a memory leak,
for instance on the `onreadystatechange` and `onload` handlers of XHR
objects, in IE.
4. etc
The pattern of explicitly assigning `undefined` to a variable that otherwise
holds some real value, and then making logic decisions based on if the
variable is in a "defined" or "undefined" state, is clear, works, and is
well known (if distasteful to some, including obviously you). I'm surprised
you're insisting that it's purely niche (it's not, I can find lots of
examples, even in major js libs) or it's bad/wrong (just because you say
so?).
But, whether it's right or wrong, it's clearly possible in the language, and
even if you dislike it, used by a lot of developers besides myself, making
it (at least a candidate for) a de facto coding pattern.
First of all, I'm talking about code where I am the consumer, so I take
care to make sure the proper checks are done.
Why don't you set doX (or just x) to the minimized value you want?
Encapsulation. Inside a class, method, module, etc, you define the base
default values for the configuration params. Then the outside user of the
API simply passes or doesn't pass what they want in, and the configuration
mixes in what they pass with what the defaults are. This is a hugely
standard pattern across tons of different public libs, including major ones
like jQuery UI, etc.
So, from the outside, simply not passing in a `coordX` property on the
`opts` config object is the most common pattern, and in general, preferable.
But, as I showed, when defining the config object using the object literal
syntax, there's no way to conditionally not add a property to the object
(you have to do that outside the object literal, in a per-statement
fashion). So, it's nice to have a way to define a property, but set its
value to `undefined`, which (relying on proper type checking/coercion-safety
inside the function) behaves exactly the same as not passing it in at all.
A hazardous pattern is no argument for syntactic sugar. At best you have a
minority use-case. At worst, it's a latent bug.
Are you suggesting that the ability to assign `undefined` to a variable or
property is so bad that it's actually a bug in the language?
Why should we add amgiguous [sic] sugar for this?
Why ever add any syntactic sugar? Whatever reason there ever is for adding
syntactic sugar, that same reason applies here. Save typing. Make code
cleaner because there's less of it. Etc etc.
At least in the case of defining an object using object literal syntax,
being able to conditionally assign `undefined` to a key (as a near
substitute for not setting the property in the first place) is helpful.
Without the sugar, there's still plenty of JavaScript coders who are going
to keep doing as I do, which is responsibly (that is, with safe type checks)
use the `undefined` value as a way to explicitly put a variable (back) into
an "unset" state, and then later make logic decisions based on if a variable
is in the "set" state or not. We'll all just keep typing the redundant `:
undefined`. And life will be fine.
But I'll also keep wishing that JavaScript had some syntactic sugar like
CoffeeScript has. CS has the pattern (as shown originally in the thread)
where the `: undefined` is omitted/implied with that ?. operator. I would
think that's a valid support for why it's at least reasonable to consider
this syntactic sugar for JavaScript.
--Kyle
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
