Pardon the top post, Brandon already seemed to dig into this
proposal with his typical surgical deftness. I just couldn't
resist relating some Flash history. As the saying goes, been
there, done that. Here's the abridged version of ActionScript's
history:
AS1 ~= ES3
AS2 == ES3 + classes as pur
On Mar 24, 2008, at 8:52 PM, Darryl wrote:
> I'd also point out that 5..prototype doesn't work,
I'm not sure what you mean by "work". 5 is not a function so it has
no pre-defined 'prototype' property. The result of 5..prototype is
therefore undefined (the undefined value), per ES3.
/be
_
On Mar 24, 2008, at 8:16 PM, Darryl wrote:
> But the all important problem with your argument,
> Brendan, is that Ruby manages to allow 5.0 to be a
> float, and 5.times to be a method call, without any
> ambiguity. If Ruby can do it, why can't JavaScript?
Please don't ask dumb rhetorical question
On Mar 24, 2008, at 6:45 PM, Mark S. Miller wrote:
> Now on to your real question. Why do I seem to believe that proposed
> ES4 is statically typed? A fair question. Proposed ES4 lies somewhere
> between the simple categories of "statically typed" and "dynamically
> typed". However, rather than fi
I'd also point out that 5..prototype doesn't work,
even tho "5." is a float, and therefore this should be
valid syntax. That hanging dot pointless, AND
inconsistent. This could just be implementation wise, ofcourse.
---
o///
Be seeing you...
__
I'll grant you one thing tho: Ruby requires "99.0"
where JS allows "99.". To be honest, saving that one
character when making whole-number valued floats
(which are indistinguishable form NON floats, i.e. 99
== 99. == 99.0), at the expense of being able to do
99.abs or something like that, is absolu
But the all important problem with your argument,
Brendan, is that Ruby manages to allow 5.0 to be a
float, and 5.times to be a method call, without any
ambiguity. If Ruby can do it, why can't JavaScript?
---
o///
Be seeing you...
_
On Mar 24, 2008, at 7:43 PM, Darryl wrote:
> In current versions of JS there's some weird stuff
> where some primitives are equal to their object
> equivalents:
>
> 1 == new Number(1)
Use === for identity testing.
> But in other cases they're not equivalents at all:
>
> typeof(1) == "number"
> t
In current versions of JS there's some weird stuff
where some primitives are equal to their object
equivalents:
1 == new Number(1)
But in other cases they're not equivalents at all:
typeof(1) == "number"
typeof(new Number(1)) == "object"
And sometimes theres weird syntax errors:
5.prototype //
On Sun, Mar 23, 2008 at 11:28 PM, Brendan Eich <[EMAIL PROTECTED]> wrote:
> ES4 is not statically typed, so...
> ... this is a false dilemma.
>
> These analogies are weak and tendentious in my opinion. Let's try to
> get back to premises and argue forward. Can we start with why you
> seem to b
-- Forwarded message --
From: Garrett Smith <[EMAIL PROTECTED]>
Date: Mon, Mar 24, 2008 at 11:27 AM
Subject: Re: Array Generics and null
To: Dean Edwards <[EMAIL PROTECTED]>
On Mon, Mar 24, 2008 at 10:31 AM, Dean Edwards <[EMAIL PROTECTED]> wrote:
> Mike Shaver wrote:
> > On Su
Mark S. Miller wrote:
> On Mon, Mar 24, 2008 at 10:31 AM, Dean Edwards <[EMAIL PROTECTED]> wrote:
>> It seems we have three choices for Array.forEach(null)
>>
>> 1) Do nothing
>> 2) Throw an exception
>> 3) Use the current object and iterate that
>
> By "current object" do you mean the global
On Sat, Mar 22, 2008 at 1:42 PM, Garrett Smith <[EMAIL PROTECTED]> wrote:
> Array generic methods will be safer if they check their args and throw
> an error - InvalidArgumentError, TypeError, UnlikeError - (whatever).
>
> Invalid: (this will crash Firefox with endless loop):-
> Array.forEach(
On Mon, Mar 24, 2008 at 10:31 AM, Dean Edwards <[EMAIL PROTECTED]> wrote:
> It seems we have three choices for Array.forEach(null)
>
> 1) Do nothing
> 2) Throw an exception
> 3) Use the current object and iterate that
By "current object" do you mean the global object?
> I prefer the first on
Mike Shaver wrote:
> On Sun, Mar 23, 2008 at 2:44 AM, Dean Edwards <[EMAIL PROTECTED]> wrote:
>> I'd prefer Array.forEach(null) to do nothing, just like for (var i in
>> null) does nothing. I'm prepared to be convinced otherwise. :-)
>
> forEach isn't like enumeration, though, it's like the more
On Sun, Mar 23, 2008 at 2:44 AM, Dean Edwards <[EMAIL PROTECTED]> wrote:
> I'd prefer Array.forEach(null) to do nothing, just like for (var i in
> null) does nothing. I'm prepared to be convinced otherwise. :-)
forEach isn't like enumeration, though, it's like the more common
Array pattern of
f
From: "David Teller" wrote:
> I concur with that. In order to maintain readability, most optimizations
> should happen behind-the-scene i.e. by using either type inference (or
> something more complicated but of the same kind) or type-feedback.
I totally agree with this; I wouldn't even have broug
On Mar 23, 2008, at 11:43 PM, Lemonade Smith wrote:
On Mon, Mar 24, 2008 at 6:28 AM, Brendan Eich <[EMAIL PROTECTED]>
wrote:
(Don't feed the trolls.)
Sorry, your name (nym?) and lack of known reputation in the
community, combined with what sounded like an echo of a "political"
document c
18 matches
Mail list logo
