Quick, possibly silly idea: What if `typeof null` returned `undefined`?
--
Dr. Axel Rauschmayer
a...@rauschma.de
home: rauschma.de
twitter: twitter.com/rauschma
blog: 2ality.com
___
es-discuss mailing list
es-discuss@mozilla.org
https
Nathan Wall wrote:
Alex Rauschmayer wrote:
Quick, possibly silly idea: What if `typeof null` returned `undefined`?
By default or after you flip a switch?
I have a better value objects draft coming, which addresses opt-in
typeof reform (cross-realm
On this tangent, I personally almost always mean isArrayish in this very
common situation. That is, indexed with a length such that almost all
Array.prototype methods would work on it out of the box. The number of
arrayish interfaces provided by host environments has continued to grow.
It's the
On May 10, 2012, at 1:05 AM, Brandon Benvie wrote:
On this tangent, I personally almost always mean isArrayish in this very
common situation. That is, indexed with a length such that almost all
Array.prototype methods would work on it out of the box. The number of
arrayish interfaces
Axel Rauschmayer wrote:
Are we going to have RegExp.isRegExp() and Date.isDate() and
Number.isNumber() etc. too ?
I did wince a bit about ES5's Array.isArray -- perhaps since it takes
any x and tells whether x is an Array (from any window or frame)
instance, it should have gone on object.
Allen Wirfs-Brock wrote:
On May 9, 2012, at 4:08 PM, Axel Rauschmayer wrote:
Are we going to have RegExp.isRegExp() and Date.isDate() and
Number.isNumber() etc. too ?
I did wince a bit about ES5's Array.isArray -- perhaps since it
takes any x and tells whether x is an Array (from any window
be helpful if someone made the case for typeof null
=== 'null'.
To me typeof null === 'object' is fine. It makes null a value in the
space of 'object'. In practice I see 'null' used to mean I know this
reference (usually an argument) should be an object; I want to pass
nothing but signal that I really
On May 10, 2012, at 1:05 AM, Brandon Benvie wrote:
On this tangent, I personally almost always mean isArrayish in this very
common situation. That is, indexed with a length such that almost all
Array.prototype methods would work on it out of the box. The number of
arrayish interfaces
Allen Wirfs-Brock wrote:
Note that in this and many other similar situations the isFoo method is actually redundant. You would get the same effect by saying:
if (obj1.doFooishThings) obj1.doFooishThings();
this suggests that a useful operator might be a conditional property access,
Brendan Eich wrote:
CoffeeScript has foo?.bar ... and foo.baz?(...) in lieu of
if (foo != null) foo.bar ...
and
if (foo.baz != null) foo.baz(...)
Correction: the ?( operator compiles like so:
$ echo 'foo={};foo.baz?()' /tmp/foo2.cs
$ ./bin/coffee -p !$
./bin/coffee -p /tmp/foo2.cs
On 9 May 2012 01:32, Brendan Eich bren...@mozilla.org wrote:
We could indeed put type-reflecting method(s) there but I'm
loath to add manifest constants. What's wrong with strings?
Depends on the mechanism. If it is supposed to be user-extensible
(i.e. an open set) then strings are bad because
Andreas Rossberg wrote:
On 9 May 2012 01:32, Brendan Eichbren...@mozilla.org wrote:
We could indeed put type-reflecting method(s) there but I'm
loath to add manifest constants. What's wrong with strings?
Depends on the mechanism. If it is supposed to be user-extensible
(i.e. an open set)
(18446744073709551615L) // uint64 literal
true
js Object.isValue({p: foo})
false
js Object.isValue(function(){})
false
js Object.isValue([1,2,3])
false
It's easy enough to revive your Object.isObject strawman that led to the
typeof null === null attempt:
js Object.isObject(null)
false
js
:
On Tue, May 8, 2012 at 6:07 PM, Brendan Eichbren...@mozilla.org wrote:
Object class reflection is frowned upon in Smalltalk for a reason. We want
protocols, structural conventions -- not nominal type tags. Or so I think!
Perhaps it would be helpful if someone made the case for typeof null
=== 'null
On May 9, 2012, at 11:43 PM, Brendan Eich wrote:
I think we should consider Object.isObject just because the typeof null
change replaced it, but 1JS killed that replacement. Also gives
Object.isValue and Array.isArray some company ;-).
Why not .isPrimitive()? We've always been talking
Jorge wrote:
On May 9, 2012, at 11:43 PM, Brendan Eich wrote:
I think we should consider Object.isObject just because the typeof null change
replaced it, but 1JS killed that replacement. Also gives Object.isValue and
Array.isArray some company ;-).
Why not .isPrimitive()?
Could do
Are we going to have RegExp.isRegExp() and Date.isDate() and
Number.isNumber() etc. too ?
I did wince a bit about ES5's Array.isArray -- perhaps since it takes any x
and tells whether x is an Array (from any window or frame) instance, it
should have gone on object. You're right that the
Axel Rauschmayer wrote:
It would be great if we could eliminate these predicates completely.
How often does the frame crossing problem matter in practice? It
doesn’t show up in non-browser environments, right?
Those matter but not so much. I know, Node.js -- I'm a fan. But really,
we have a
On May 10, 2012, at 1:08 AM, Axel Rauschmayer wrote:
Are we going to have RegExp.isRegExp() and Date.isDate() and
Number.isNumber() etc. too ?
I did wince a bit about ES5's Array.isArray -- perhaps since it takes any x
and tells whether x is an Array (from any window or frame) instance,
- Introduce a binary predicate, e.g. likeInstanceOf that correctly handles
cases where the lhs and rhs come from different contexts/frames.
Again, how? The name of the constructor in one frame may not be relevant in
the other. The constructor may not be a built-in. Are you thinking in
On May 9, 2012, at 4:08 PM, Axel Rauschmayer wrote:
Are we going to have RegExp.isRegExp() and Date.isDate() and
Number.isNumber() etc. too ?
I did wince a bit about ES5's Array.isArray -- perhaps since it takes any x
and tells whether x is an Array (from any window or frame) instance,
Good points. In hindsight, my complaint was more about things currently being a
bit confusing (one frequently reads that one shouldn’t use instanceof Array)
than about proposing a specific solution. So the comment below helps.
On May 10, 2012, at 4:53 , Allen Wirfs-Brock wrote:
The reason
Aware that that typeof null has been rejected, but I was wondering if it
could be revived via the implicit opt-in path, eg:
non-strict, non-opt-in:
typeof null === null; // false
implied opt-in:
module Foo {
export function create( options ) {
if ( typeof options === null
It looks to me like this code would work just fine by removing the word
'typeof'. What am I missing?
On 8 May 2012 12:19, Rick Waldron waldron.r...@gmail.com wrote:
module Foo {
export function create( options ) {
if ( typeof options === null ) {
return ... some default thing;
Wes Garland wrote:
It looks to me like this code would work just fine by removing the word
'typeof'. What am I missing?
Cross-frame/cross-context, too?
On 8 May 2012 12:19, Rick Waldron waldron.r...@gmail.com
mailto:waldron.r...@gmail.com wrote:
module Foo {
export function
On Tue, May 8, 2012 at 12:42 PM, Wes Garland w...@page.ca wrote:
It looks to me like this code would work just fine by removing the word
'typeof'. What am I missing?
Sure, but that wasn't the point, I was simple trying to create an example
piece of code that would trigger the opt-in
Rick
On Tue, May 8, 2012 at 12:52 PM, Herby Vojčík he...@mailbox.sk wrote:
Wes Garland wrote:
It looks to me like this code would work just fine by removing the word
'typeof'. What am I missing?
Cross-frame/cross-context, too?
I guess this answers my question, because if code can get from
, 2012, at 18:19 , Rick Waldron wrote:
Aware that that typeof null has been rejected, but I was wondering if it
could be revived via the implicit opt-in path, eg:
non-strict, non-opt-in:
typeof null === null; // false
implied opt-in:
module Foo {
export function create( options
On May 8, 2012, at 9:19 AM, Rick Waldron wrote:
non-strict, non-opt-in:
typeof null === null; // false
implied opt-in:
Changing typeof null always seemed questionable to me in terms of value. It
doesn't really give you significant new functionality, it just kinda seems
more sensible
(or something
similar, e.g. from a reflection API) and objects o to o.constructor.
On May 8, 2012, at 23:45 , David Herman wrote:
On May 8, 2012, at 9:19 AM, Rick Waldron wrote:
non-strict, non-opt-in:
typeof null === null; // false
implied opt-in:
Changing typeof null always seemed
Constants? We don't need no stinking constants! :-P Manifest strings, a
la typeof, are the natural and self-describing upgrade path, if we're
talking typeof (see Subject).
The Reflect namespace object is part of direct proxies, also populated
in SpiderMonkey (not web-facing) by Reflect.parse
Constants? We don't need no stinking constants! :-P Manifest strings, a la
typeof, are the natural and self-describing upgrade path, if we're talking
typeof (see Subject).
The Reflect namespace object is part of direct proxies, also populated in
SpiderMonkey (not web-facing) by
Axel Rauschmayer wrote:
Constants? We don't need no stinking constants! :-P Manifest strings,
a la typeof, are the natural and self-describing upgrade path, if
we're talking typeof (see Subject).
The Reflect namespace object is part of direct proxies, also
populated in SpiderMonkey (not
On Tue, May 8, 2012 at 6:07 PM, Brendan Eich bren...@mozilla.org wrote:
Object class reflection is frowned upon in Smalltalk for a reason. We want
protocols, structural conventions -- not nominal type tags. Or so I think!
Perhaps it would be helpful if someone made the case for typeof null
No. I would rather an upgrade for typeof, than something that tries to do two
different things under one API.
Are those two things so different, though? Most people only need to know about
the difference between primitive values and objects, because of typeof and
instanceof.
If the “new
Hey list,
just wanted to ask what's going to happen with typeof null, i am a lot
in the favor of changing it to say null. Changing this was discussed
here http://wiki.ecmascript.org/doku.php?id=strawman:object_isobject
and http://wiki.ecmascript.org/doku.php?id=proposals:typeof. I think
´typeof
to compile a
browser with that change and surf around a bit and see how it goes? google,
amazon, facebook, etc.
Andreas
On Apr 19, 2011, at 2:56 PM, Tom Schuster wrote:
Hey list,
just wanted to ask what's going to happen with typeof null, i am a lot
in the favor of changing it to say null
Hang on. The proposal is to change typeof null == null only under opt-in to
Harmony.
http://wiki.ecmascript.org/doku.php?id=strawman:object_isobject
I'll rewrite this as a harmony:typeof proposal for the next TC39 meeting, but
it's already harmonious in concept.
/be
On Apr 19, 2011, at 3:03
Oh missed that wiki page. Good to see this going, created
https://bugzilla.mozilla.org/show_bug.cgi?id=651251 anyways.
(Sorry brendan, didn't meant to write to you, post mailing list generation here)
___
es-discuss mailing list
es-discuss@mozilla.org
39 matches
Mail list logo
