This is expected and by design. For example obj[‘#invalidPrivateSigil’] is also
not invalid. The affordances would be the same.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
> Le 29 janv. 2019 à 08:45, Sultan Tarimo a écrit :
>
> That is obj.font-size would rightly be invalid.
Sadly, `obj.font-size` is *not* invalid, it has some well-defined semantics.
That would be a source of bugs
—Claude___
es-discuss mailing
That might have been the case, but the expectation that an unquoted form should
equally have a quoted form or vice-versa is not an issue in practice given the
presence of a similar but opposite semantic in the private sigil access
notation proposal: object.#validPrivateSigil ->
i think if i can use something unquoted in an object literal, i'd expect to
be able to use it in dot access - ie, `obj.font-size` - and then that
problem arises.
On Mon, Jan 28, 2019 at 3:43 PM Sultan Tarimo wrote:
> The former as the following is equally invalid syntax errors:
>
> const font =
The former as the following is equally invalid syntax errors:
const font = 1
const size = 1
const a = {
font-size: 10
}
const b = {
font+size: 10
}
___
es-discuss mailing list
es-discuss@mozilla.org
is that a key called "font-size" or the subtraction of `size` from `font`?
On Mon, Jan 28, 2019 at 1:48 PM Sultan wrote:
> Is there any reason that dash-case keys are not supported in the object
> literal syntax.
>
> For example:
>
> const style = {
> font-size: 10
> }
>
> Compared to what
Is there any reason that dash-case keys are not supported in the object
literal syntax.
For example:
const style = {
font-size: 10
}
Compared to what one needs to do today:
const style = {
'font-size': 10
}
___
es-discuss mailing list
Yeah! The static version of this is definitely something I see as a natural
next step.
From my observation, tc39 proposals seem to take on the instance and static
versions of a feature separately. So for that reason it wasn’t mentioned.
But yes, if this proposal somehow made it through the
Thank you all so much for the feedback! The push-back has given me something to
more to consider.
I’d like to add a couple points which are hopefully clarifying, but I do
acknowledge the idea doesn’t seem to be attracting positive interest in its
current form.
I meant to note in the original
Isiah: good find. I was just being sloppy to get the idea across.
J. Decker: The code I gave was just an example of how to do it if it was
for some reason absolutely necessary to use `class`. I don't see the need
and would either tend toward your approach, or just somehow refactor away
the need
On Sun, Jan 27, 2019 at 10:46 PM Ranando King wrote:
> Jordan's right. This one is best handled by a function. But if there is
> some reason you need to create callable objects, it's still doable, even
> with ES as-is. Just extend your classes from something like this:
>
> ```js
> class Callable
Nit: you may need to reset the function's prototype. Also, `create` should
probably be static. ;-)
On Mon, Jan 28, 2019 at 01:46 Ranando King wrote:
> Jordan's right. This one is best handled by a function. But if there is
> some reason you need to create callable objects, it's still doable,
12 matches
Mail list logo
