Le 03/08/2013 20:44, Brendan Eich a écrit :
> David Bruant wrote:
>> I don't see the benefit of that against a file/function-wise directive.
>
> Lexical means block in the modern Harmony era.
Excellent.

>> For both null and the new value types, I'm still unclear on why could 
>> devs would choose something different than the default. I feel the 
>> incentives can only [weigh] in favor of keeping the default. I'm 
>> interested in what other devs think.
>
> I'm not sure what you mean re: "new value types". They have no 
> "default" and "object" fails usability and useful-invariant requirements.
I need to re-read the proposal more in depth.

> For null, are you sure people won't choose to "repair" this "ES 
> regret" ? :-P
I'm doubtful for myself, but I'm really interested in what other devs 
think (but maybe we're too deep in thread nesting to have a big dev 
audience any longer :-p)
This is quite a challenge to rewrite code to repair this regret. Maybe 
people have code that do (typeof x === typeof y) and expect null to come 
as an object. People coming from a Java background feel like typeof null 
=== "object" is nothing but normal. The fact that 
Object.getPrototypeOf(Object.prototype) returns null also encourages 
this line of reasoning.
I also recall that for one specific case [1] (oh! the indentation is 
awful!), I needed to play with the value returned by typeof (so doing 
more than just typeof x === y). That's very specific, but that would 
take time for me to transition to the repaired version of typeof with 
the same level of confidence. Just to save 20 chars, that doesn't sound 
like trouble I'd care to go into.

That said, I recently worked on a project and I reviewed a pull request 
with "typeof x === 'object'" to ask to replace to 'Object(x) === x'. I 
guess it would be nice if handling null didn't require encyclopedic 
knowledge of the language. But that's an opt-in and as of 2013, maybe 
2014, I imagine that those who will know about how to fix typeof with 
the opt-in, will also know why it's there and how to avoid trouble in 
their own code.

Sorry for the hot and cold. Trying to share all relevant experience as a 
developer.

David

[1] (this line and 3 lines below) 
https://github.com/DavidBruant/ObjectViz/blob/ae4000925542f9393dc456be83566afa95bb35df/js/ObjectOwnViz.js#L92

Le 03/08/2013 20:44, Brendan Eich a écrit :
> David Bruant wrote:
>> I don't see the benefit of that against a file/function-wise directive.
>
> Lexical means block in the modern Harmony era.

Excellent.

>> For both null and the new value types, I'm still unclear on why could 
>> devs would choose something different than the default. I feel the 
>> incentives can only [weigh] in favor of keeping the default. I'm 
>> interested in what other devs think.
>
> I'm not sure what you mean re: "new value types". They have no 
> "default" and "object" fails usability and useful-invariant requirements.

I need to re-read the proposal more in depth.

> For null, are you sure people won't choose to "repair" this "ES 
> regret" ? :-P

I'm doubtful for myself, but I'm really interested in what other devs 
think (but maybe we're too deep in thread nesting to have a big dev 
audience any longer :-p)
This is quite a challenge to rewrite code to repair this regret. Maybe 
people have code that do (typeof x === typeof y) and expect null to come 
as an object. People coming from a Java background feel like typeof null === "object" is nothing but normal. The fact that 
Object.getPrototypeOf(Object.prototype) returns null also encourages 
this line of reasoning.
I also recall that for one specific case [1] (oh! the indentation is 
awful!), I needed to play with the value returned by typeof (so doing 
more than just typeof x === y). That's very specific, but that would 
take time for me to transition to the repaired version of typeof with 
the same level of confidence. Just to save 20 chars, that doesn't sound 
like trouble I'd care to go into.

That said, I recently worked on a project and I reviewed a pull request 
with "typeof x === 'object'" to ask to replace to 'Object(x) === x'. I 
guess it would be nice if handling null didn't require encyclopedic 
knowledge of the language. But that's an opt-in and as of 2013, maybe 
2014, I imagine that those who will know about how to fix typeof with 
the opt-in, will also know why it's there and how to avoid trouble in 
their own code.

Sorry for the hot and cold. Trying to share all relevant experience as a 
developer.

[1] (this line and 3 lines below) 
https://github.com/DavidBruant/ObjectViz/blob/ae4000925542f9393dc456be83566afa95bb35df/js/ObjectOwnViz.js#L92