Re: How it feels to learn JavaScript in 2016
`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 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 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 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 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, th
Re: How it feels to learn JavaScript in 2016
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 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 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 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 wrote: >>> > >>> >> Le 25 nov. 2017 à 16:03, kai zhu 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 >>> 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 >> > ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: How it feels to learn JavaScript in 2016
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 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 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 wrote: >> > >> >> Le 25 nov. 2017 à 16:03, kai zhu 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 >> 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 > ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Allow specify numbers with suffixes
Thank for your answers
Jerry, I think that in tagged template literals form it won't be widely used
e.g. `setTimeout(foo, millis`30s`);` is much harder to read than
`setTimeout(foo,
3);`
---
Regarding https://github.com/littledan/proposal-extensible-numeric-literals:
Doesn't conflict with this idea.
Also looks great at first sight. BTW - In my personal opinion - in most
cases number suffixes/literals/syntaxes are just sugar, and must be
processed at compile-time (0xFF00 syntax is also just sugar).
Also to make this proposal useful - JS also need to support operators
overloading, without operator overloading do something useful while writing
`10px + 1em` is impossible, so it decreases usability of this innovation to
just another way of calling function(for now).
So in my _personal_ opinion, for now it is better to stay with fixed list
of built-in compile-time executed number suffixes/literals
---
Regarding https://github.com/tc39/proposal-bigint
The only problem between proposals is the suffix `n` which specifies 10^-9.
Few thoughts:
- milli, nano, etc. suffixes won't be widely used
- they always can be replaced with expotential notation 1e-3, 1e-6, ...
So they are removed from this idea,
Also removed full form, as it doesn't look semantically valid
Updated list of sugar suffixes:
- Usable list analogues of 1e3, 1e6, 1e9:
- 1K = 1000 = 1e3
- 1M = 1000*1000 = 1e6
- 1G = 1000*1000*1000 = 1e9
- ... (T,P,E,Z,Y)
- The same with bytes, nobody will count nanobytes... Isn't it? Usable
list:
- 1KB = 1024
- 1MB = 1024*1024
- 1GB = 1024*1024*1024
- ... (TB,PB,EB,ZB,YB)
- Updated time group, this can make life easier for each novice...
- 1s = 1000
- 1m = 60s
- 1h = 60m
- 1d = 24h
- 1w = 7d
How it looks for you with updates?
Best regards,
Andrey
2017-11-25 1:22 GMT+02:00 Jerry Schulteis :
> I see the BigInt proposal at the moment uses a suffix 'n' for BigInt
> literals.
> That would conflict with Andrey's desire to have it mean metric nano (*
> 10**-9).
> Maybe tagged template literals would do?
> populationSize = SI`100M`;
> setTimeout(foo, millis`30s`);
>
> On Thursday, November 23, 2017, 7:22:41 AM CST, Isiah Meadows <
> isiahmead...@gmail.com> wrote:
>
>
> Check out the various unit-related proposals that have spawned on this
> list, and note that IIRC the BigInt proposal [1] also notes that as a
> possible future expansion.
>
> [1]: https://github.com/tc39/proposal-bigint
>
> On Thu, Nov 23, 2017, 08:17 Andrey Muzalevsky
> wrote:
>
> Idea is simple, also is simple to implement and do not conflicting with
> existing standard
>
> Readability of javascript can be improved in certain cases like:
>
>- populationSize = 1
>- maxMessageSize = 4194304
>- setTimeout(foo, 3)
>- if(timeElapsed > 100) {...}
>
> This can be changed to following:
>
>- populationSize = 100M
>- maxMessageSize = 4MB
>- setTimeout(foo, 30s)
>- if(timeElapsed > 0.1s) {...}
>
> Also it will be great to support floating number, most convinient way to
> do this is tract suffix just like a multipler, so
>
> 1.5MB == 1.5 * 1MB
>
> Supported suffixes, as I see them:
>
>- Metric prefixes group
> - follow SI Prefixes
>
