How it feels to learn JavaScript in 2016

classic Classic list List threaded Threaded
28 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Re: How it feels to learn JavaScript in 2016

kai zhu
i disagree.  you can write more maintainable and cleaner code with the
premise typeof's will never change again (and give a one-time pass for
symbols), instead of over-engineered paranoid code that it *may*
change again in the future.


On 11/25/17, Oriol _ <[hidden email]> wrote:

> It was kind of obvious that checking whether some value is an object by
> ensuring that it's not any of the existing primitives would stop working if
> a new primitive was added, which effectively happened with symbols. If some
> library used that, I think it is to blame. Instead, I would recommend
> something more simple and reliable like
>
>
> ```js
> function isObject(value) {
>   return Object(value) === value;
> }
> function isObject(value) {
>   return new function(){ return value } === value;
> }
> ```
>
> --Oriol
>
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: How it feels to learn JavaScript in 2016

T.J. Crowder-2
In reply to this post by kai zhu
On Sat, Nov 25, 2017 at 6:09 AM, kai zhu <[hidden email]> wrote:
> introducing the new typeof Symbol() === 'symbol' does break
> backwards compatibility with many es5 libraries that default to
> 'object' type if typeof is not 'boolean', 'number', 'string',
> 'function', or 'undefined'.

Which ones, **specifically**?

-- T.J. Crowder
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: How it feels to learn JavaScript in 2016

Claude Pache
In reply to this post by kai zhu

> Le 25 nov. 2017 à 16:03, kai zhu <[hidden email]> a écrit :
>
> i disagree.  you can write more maintainable and cleaner code with the
> premise typeof's will never change again (and give a one-time pass for
> symbols), instead of over-engineered paranoid code that it *may*
> change again in the future.
>

It is the responsibility of the programmer to write *forward-compatible* code, i.e., code that does not make assumptions that are *likely* to break in the future. For instance, one can *reasonably* think that the domain of the `typeof` operator may expand.

Naturally, the programmer should be smart enough in order to make the difference between paranoia and common sense: this is part of the art of programming.

—Claude

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: How it feels to learn JavaScript in 2016

kai zhu
claude, mature nodejs database drivers with frozen business logic for
stability reasons are examples of libraries that you are asking to
change whenever tc39 decides to expand typeof's on a whim which may
break them.

the maintainers of sqlite3 for example have stated its in maintennance
mode (https://github.com/mapbox/node-sqlite3/issues/870), and all
commits for the past 2 years have dealt exclusively with its build
process so it can successfully compile with each nodejs release.

i write database code myself.  what was my reaction to the
introduction of the 'symbol' typeof?  annoyance at trying to figure
out what pathological use-case a user might want to pass a 'symbol'
type to the database.  i imagine mongodb / mysql / sqlite3 maintainers
are equally annoyed with trying to figure that out.  if tc39 had
treated symbols as a regular 'object' type, then we wouldn't have that
problem, and the current undefined behavior when its encountered in db
drivers.


On 11/26/17, Claude Pache <[hidden email]> wrote:

>
>> Le 25 nov. 2017 à 16:03, kai zhu <[hidden email]> a écrit :
>>
>> i disagree.  you can write more maintainable and cleaner code with the
>> premise typeof's will never change again (and give a one-time pass for
>> symbols), instead of over-engineered paranoid code that it *may*
>> change again in the future.
>>
>
> It is the responsibility of the programmer to write *forward-compatible*
> code, i.e., code that does not make assumptions that are *likely* to break
> in the future. For instance, one can *reasonably* think that the domain of
> the `typeof` operator may expand.
>
> Naturally, the programmer should be smart enough in order to make the
> difference between paranoia and common sense: this is part of the art of
> programming.
>
> —Claude
>
>
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: How it feels to learn JavaScript in 2016

Jordan Harband
Except that they're not regular objects; and if they'd done that, there'd just be the same potential problems with code naively written to accept an object (since Symbols are primitives, they don't have persistent properties, for example).

Code that's written as if things will never change is brittle; "paranoid" code isn't over-engineered, it's simply *engineered* to handle change robustly.

On Sat, Nov 25, 2017 at 5:30 PM, kai zhu <[hidden email]> wrote:
claude, mature nodejs database drivers with frozen business logic for
stability reasons are examples of libraries that you are asking to
change whenever tc39 decides to expand typeof's on a whim which may
break them.

the maintainers of sqlite3 for example have stated its in maintennance
mode (https://github.com/mapbox/node-sqlite3/issues/870), and all
commits for the past 2 years have dealt exclusively with its build
process so it can successfully compile with each nodejs release.

i write database code myself.  what was my reaction to the
introduction of the 'symbol' typeof?  annoyance at trying to figure
out what pathological use-case a user might want to pass a 'symbol'
type to the database.  i imagine mongodb / mysql / sqlite3 maintainers
are equally annoyed with trying to figure that out.  if tc39 had
treated symbols as a regular 'object' type, then we wouldn't have that
problem, and the current undefined behavior when its encountered in db
drivers.


On 11/26/17, Claude Pache <[hidden email]> wrote:
>
>> Le 25 nov. 2017 à 16:03, kai zhu <[hidden email]> a écrit :
>>
>> i disagree.  you can write more maintainable and cleaner code with the
>> premise typeof's will never change again (and give a one-time pass for
>> symbols), instead of over-engineered paranoid code that it *may*
>> change again in the future.
>>
>
> It is the responsibility of the programmer to write *forward-compatible*
> code, i.e., code that does not make assumptions that are *likely* to break
> in the future. For instance, one can *reasonably* think that the domain of
> the `typeof` operator may expand.
>
> Naturally, the programmer should be smart enough in order to make the
> difference between paranoia and common sense: this is part of the art of
> programming.
>
> —Claude
>
>
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss


_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: How it feels to learn JavaScript in 2016

Alexander Jones
They’re not even *objects*, let alone regular objects! :)

Making every new addition to the language be a subtype of object just creates a worse language. Given the constraints and requirements it was the right choice to make symbol a new primitive. Technically it “broke the web”, like literally every new change to the language. But that’s not as black and white as people make it out to be, by using such a catchy phrase.

typeof: officially subject to extensions.

Alex

On Sun, 26 Nov 2017 at 01:23, Jordan Harband <[hidden email]> wrote:
Except that they're not regular objects; and if they'd done that, there'd just be the same potential problems with code naively written to accept an object (since Symbols are primitives, they don't have persistent properties, for example).

Code that's written as if things will never change is brittle; "paranoid" code isn't over-engineered, it's simply *engineered* to handle change robustly.

On Sat, Nov 25, 2017 at 5:30 PM, kai zhu <[hidden email]> wrote:
claude, mature nodejs database drivers with frozen business logic for
stability reasons are examples of libraries that you are asking to
change whenever tc39 decides to expand typeof's on a whim which may
break them.

the maintainers of sqlite3 for example have stated its in maintennance
mode (https://github.com/mapbox/node-sqlite3/issues/870), and all
commits for the past 2 years have dealt exclusively with its build
process so it can successfully compile with each nodejs release.

i write database code myself.  what was my reaction to the
introduction of the 'symbol' typeof?  annoyance at trying to figure
out what pathological use-case a user might want to pass a 'symbol'
type to the database.  i imagine mongodb / mysql / sqlite3 maintainers
are equally annoyed with trying to figure that out.  if tc39 had
treated symbols as a regular 'object' type, then we wouldn't have that
problem, and the current undefined behavior when its encountered in db
drivers.


On 11/26/17, Claude Pache <[hidden email]> wrote:
>
>> Le 25 nov. 2017 à 16:03, kai zhu <[hidden email]> a écrit :
>>
>> i disagree.  you can write more maintainable and cleaner code with the
>> premise typeof's will never change again (and give a one-time pass for
>> symbols), instead of over-engineered paranoid code that it *may*
>> change again in the future.
>>
>
> It is the responsibility of the programmer to write *forward-compatible*
> code, i.e., code that does not make assumptions that are *likely* to break
> in the future. For instance, one can *reasonably* think that the domain of
> the `typeof` operator may expand.
>
> Naturally, the programmer should be smart enough in order to make the
> difference between paranoia and common sense: this is part of the art of
> programming.
>
> —Claude
>
>
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: How it feels to learn JavaScript in 2016

kai zhu
neither is null really an object, which for all practical purpose is
treated like a primitive, but the precedent was set to make it an
object.  symbol changed that precedent.

> typeof: officially subject to extensions.
we agree to disagree.  my opinion is introducing more types will only
make things that were simple more complicated.

-kai

On 11/27/17, Alexander Jones <[hidden email]> wrote:

> They’re not even *objects*, let alone regular objects! :)
>
> Making every new addition to the language be a subtype of object just
> creates a worse language. Given the constraints and requirements it was the
> right choice to make symbol a new primitive. Technically it “broke the
> web”, like literally every new change to the language. But that’s not as
> black and white as people make it out to be, by using such a catchy phrase.
>
> typeof: officially subject to extensions.
>
> Alex
>
> On Sun, 26 Nov 2017 at 01:23, Jordan Harband <[hidden email]> wrote:
>
>> Except that they're not regular objects; and if they'd done that, there'd
>> just be the same potential problems with code naively written to accept
>> an
>> object (since Symbols are primitives, they don't have persistent
>> properties, for example).
>>
>> Code that's written as if things will never change is brittle; "paranoid"
>> code isn't over-engineered, it's simply *engineered* to handle change
>> robustly.
>>
>> On Sat, Nov 25, 2017 at 5:30 PM, kai zhu <[hidden email]> wrote:
>>
>>> claude, mature nodejs database drivers with frozen business logic for
>>> stability reasons are examples of libraries that you are asking to
>>> change whenever tc39 decides to expand typeof's on a whim which may
>>> break them.
>>>
>>> the maintainers of sqlite3 for example have stated its in maintennance
>>> mode (https://github.com/mapbox/node-sqlite3/issues/870), and all
>>> commits for the past 2 years have dealt exclusively with its build
>>> process so it can successfully compile with each nodejs release.
>>>
>>> i write database code myself.  what was my reaction to the
>>> introduction of the 'symbol' typeof?  annoyance at trying to figure
>>> out what pathological use-case a user might want to pass a 'symbol'
>>> type to the database.  i imagine mongodb / mysql / sqlite3 maintainers
>>> are equally annoyed with trying to figure that out.  if tc39 had
>>> treated symbols as a regular 'object' type, then we wouldn't have that
>>> problem, and the current undefined behavior when its encountered in db
>>> drivers.
>>>
>>>
>>> On 11/26/17, Claude Pache <[hidden email]> wrote:
>>> >
>>> >> Le 25 nov. 2017 à 16:03, kai zhu <[hidden email]> a écrit :
>>> >>
>>> >> i disagree.  you can write more maintainable and cleaner code with
>>> >> the
>>> >> premise typeof's will never change again (and give a one-time pass
>>> >> for
>>> >> symbols), instead of over-engineered paranoid code that it *may*
>>> >> change again in the future.
>>> >>
>>> >
>>> > It is the responsibility of the programmer to write
>>> > *forward-compatible*
>>> > code, i.e., code that does not make assumptions that are *likely* to
>>> break
>>> > in the future. For instance, one can *reasonably* think that the
>>> > domain
>>> of
>>> > the `typeof` operator may expand.
>>> >
>>> > Naturally, the programmer should be smart enough in order to make the
>>> > difference between paranoia and common sense: this is part of the art
>>> > of
>>> > programming.
>>> >
>>> > —Claude
>>> >
>>> >
>>> _______________________________________________
>>> es-discuss mailing list
>>> [hidden email]
>>> https://mail.mozilla.org/listinfo/es-discuss
>>>
>>
>> _______________________________________________
>> es-discuss mailing list
>> [hidden email]
>> https://mail.mozilla.org/listinfo/es-discuss
>>
>
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: How it feels to learn JavaScript in 2016

Logan Smyth
`typeof null` is `"object"` for entirely historical implementation reasons, not because things that don't fit the existing primitive list are automatically `object`. Adding a new typeof `symbol` doesn't change a precedent, because there was no such precedent. I understand that it's not what you want, but that doesn't make it the wrong choice for the language. 

If Symbols had been made typeof `"object"`, we'd have way more people on here complaining about the exact opposite expectation that code like this would work, where they assumed that `object` meant something that could have properties added to it.
```
function addState(obj) {
  if (typeof obj !== "object" || obj === null) throw new Error("State can only be added to objects");
  Object.defineProperty(obj, "state", {value: ""});
}
```
for instance if it were `"object"` instead, this would pass the library's check and then throw because you can't define properties on a symbol, instead of the nice error that the library author intended.

Adding additional typeof results also allows developers to write code defensively. A dev could absolutely write
```
switch(typeof foo) {
  case "undefined":
  case "object":
  case "number":
  case "string":
  case "boolean":
    // handle normally
    break;
  default:
    throw new Error(`Unexpected value with ${typeof foo}`);
}
```
to enforce their assumptions about type, and give the user helpful feedback if new types are added in the future. If Symbol had been added as `"object"`, there's is no way for developers to do this. Someone can guess "maybe a new typeof will be added", but they would be super unlikely to guess that a new object type would be added that didn't behave like any other thing with typeof `"object".

At the end of the day, a new data type is always going to break assumptions made somewhere, independent of whether there is a new `typeof` result or not, and if that's already the case, adding a new typeof is much more consistent with the types already in the language because Symbols do not behave like normal objects.

I can't tell from what you've said so far, is your complaint that a new `typeof` result was added, or is it that Symbols aren't actual objects? If the complaint is entirely about `typeof` then I feel like my above comments mostly make that clear, but if your issue is just that they should have conceptually been objects, then I don't feel like you've made it clear why that would be better than a new primitive (independent of typeof).

On Sun, Nov 26, 2017 at 11:54 AM, kai zhu <[hidden email]> wrote:
neither is null really an object, which for all practical purpose is
treated like a primitive, but the precedent was set to make it an
object.  symbol changed that precedent.

> typeof: officially subject to extensions.
we agree to disagree.  my opinion is introducing more types will only
make things that were simple more complicated.

-kai

On 11/27/17, Alexander Jones <[hidden email]> wrote:
> They’re not even *objects*, let alone regular objects! :)
>
> Making every new addition to the language be a subtype of object just
> creates a worse language. Given the constraints and requirements it was the
> right choice to make symbol a new primitive. Technically it “broke the
> web”, like literally every new change to the language. But that’s not as
> black and white as people make it out to be, by using such a catchy phrase.
>
> typeof: officially subject to extensions.
>
> Alex
>
> On Sun, 26 Nov 2017 at 01:23, Jordan Harband <[hidden email]> wrote:
>
>> Except that they're not regular objects; and if they'd done that, there'd
>> just be the same potential problems with code naively written to accept
>> an
>> object (since Symbols are primitives, they don't have persistent
>> properties, for example).
>>
>> Code that's written as if things will never change is brittle; "paranoid"
>> code isn't over-engineered, it's simply *engineered* to handle change
>> robustly.
>>
>> On Sat, Nov 25, 2017 at 5:30 PM, kai zhu <[hidden email]> wrote:
>>
>>> claude, mature nodejs database drivers with frozen business logic for
>>> stability reasons are examples of libraries that you are asking to
>>> change whenever tc39 decides to expand typeof's on a whim which may
>>> break them.
>>>
>>> the maintainers of sqlite3 for example have stated its in maintennance
>>> mode (https://github.com/mapbox/node-sqlite3/issues/870), and all
>>> commits for the past 2 years have dealt exclusively with its build
>>> process so it can successfully compile with each nodejs release.
>>>
>>> i write database code myself.  what was my reaction to the
>>> introduction of the 'symbol' typeof?  annoyance at trying to figure
>>> out what pathological use-case a user might want to pass a 'symbol'
>>> type to the database.  i imagine mongodb / mysql / sqlite3 maintainers
>>> are equally annoyed with trying to figure that out.  if tc39 had
>>> treated symbols as a regular 'object' type, then we wouldn't have that
>>> problem, and the current undefined behavior when its encountered in db
>>> drivers.
>>>
>>>
>>> On 11/26/17, Claude Pache <[hidden email]> wrote:
>>> >
>>> >> Le 25 nov. 2017 à 16:03, kai zhu <[hidden email]> a écrit :
>>> >>
>>> >> i disagree.  you can write more maintainable and cleaner code with
>>> >> the
>>> >> premise typeof's will never change again (and give a one-time pass
>>> >> for
>>> >> symbols), instead of over-engineered paranoid code that it *may*
>>> >> change again in the future.
>>> >>
>>> >
>>> > It is the responsibility of the programmer to write
>>> > *forward-compatible*
>>> > code, i.e., code that does not make assumptions that are *likely* to
>>> break
>>> > in the future. For instance, one can *reasonably* think that the
>>> > domain
>>> of
>>> > the `typeof` operator may expand.
>>> >
>>> > Naturally, the programmer should be smart enough in order to make the
>>> > difference between paranoia and common sense: this is part of the art
>>> > of
>>> > programming.
>>> >
>>> > —Claude
>>> >
>>> >
>>> _______________________________________________
>>> es-discuss mailing list
>>> [hidden email]
>>> https://mail.mozilla.org/listinfo/es-discuss
>>>
>>
>> _______________________________________________
>> es-discuss mailing list
>> [hidden email]
>> https://mail.mozilla.org/listinfo/es-discuss
>>
>
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss


_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
12