I do understand that just switching a skin is no go, but having something
like:
use clean;
Could be a very good compromise.
Regarding my phrase on coffee: I did not meant to heart anybody's feelings
regarding coffee script. I do like the project myself but I don't think it
production ready.
FWIW: Clojure (the new Lisp) uses (identical? a b)
I don't know why Rich Hickey dropped 'eq?' and went with 'identical?', but I
like it.
Cheers,
Tom
2010/9/7 Brendan Eich bren...@mozilla.com
On Sep 7, 2010, at 9:34 AM, Ash Berlin wrote:
On 7 Sep 2010, at 17:18, P T Withington wrote:
On
On 2010-09-05, at 10:33, Mark S. Miller wrote:
http://wiki.ecmascript.org/doku.php?id=strawman:classes_as_sugar
Of the three straw contenders for this niche, my preference order continues
to be
* Traits
If I had a vote, it would be +1
* Classes as Sugar
* Enhanced Object Literals
But
On Wed, Sep 8, 2010 at 10:16 AM, P T Withington p...@pobox.com wrote:
On 2010-09-05, at 10:33, Mark S. Miller wrote:
http://wiki.ecmascript.org/doku.php?id=strawman:classes_as_sugar
Of the three straw contenders for this niche, my preference order continues
to be
* Traits
If I had a vote,
But since Traits seems to be blocked from advancing,
Is there someplace I should read to understand why Traits cannot advance?
I asked MarkM off-list what the reason was, and he replied that there
was an objection (raised by Waldemar?) to how class evolution was
handled.
My feeling, and
On Wed, Sep 8, 2010 at 12:52 PM, David Herman dher...@mozilla.com wrote:
But since Traits seems to be blocked from advancing,
Is there someplace I should read to understand why Traits cannot advance?
I asked MarkM off-list what the reason was, and he replied that there
was an objection
On Sep 8, 2010, at 12:52 PM, David Herman wrote:
But since Traits seems to be blocked from advancing,
Is there someplace I should read to understand why Traits cannot advance?
I asked MarkM off-list what the reason was, and he replied that there
was an objection (raised by Waldemar?) to
On Sep 8, 2010, at 15:52, David Herman dher...@mozilla.com wrote:
libraries should generally be very widely used and very stable before they
are added to the ES standard library.
That would seem like an unfair penalty. Am I to infer classes-as-sugar OS
preferred because it _can't_ be
Does that feeling carry over to any variants that might actually
include new syntax?
The issue isn't whether it introduces new syntax, it's whether it introduces
new semantics. The Traits library, as written, is completely implementable as a
library in the existing language.
That's not to
On Sep 8, 2010, at 2:37 PM, P T Withington wrote:
On Sep 8, 2010, at 15:52, David Herman dher...@mozilla.com wrote:
libraries should generally be very widely used and very stable before they
are added to the ES standard library.
That would seem like an unfair penalty. Am I to infer
On Wed, Sep 8, 2010 at 2:39 PM, David Herman dher...@mozilla.com wrote:
Does that feeling carry over to any variants that might actually
include new syntax?
The issue isn't whether it introduces new syntax, it's whether it introduces
new semantics. The Traits library, as written, is
libraries should generally be very widely used and very stable before they
are added to the ES standard library.
That would seem like an unfair penalty. Am I to infer classes-as-sugar OS
preferred because it _can't_ be implemented as a library (despite being a
more experimental approach,
Agreed; perhaps my question was not clear. If there was a Traits-like
proposal that did include new syntax, would you be against it because
you can implement something similar as a library without needing new
semantics, or would you be more inclined to reserve judgement until
you could
On Tue, Sep 7, 2010 at 7:21 PM, Brendan Eich bren...@mozilla.com wrote:
Anyone know of bad advice somewhere, or a code generator doing the prepending,
or anything else we should evangelize aggressively either to stop pasting
use strict;
blindly, or do do the testing to make sure the code
The other problem with JSLint is that it can't run all of the code so JSLint
won't pick up the runtime error in
function f() {
use strict;
return this.foo;
}
f();
I've seen a couple of sites that would break due to this.
--Oliver
On Sep 8, 2010, at 3:16 PM, Marek Stępień wrote:
On
in the Names strawman, private foo at the top level has the same
problem as use strict at the top level. maybe there should be a
general way of delimiting a top-level lexical scope, so that pasting js
together is still relatively easy?
___
On Wed, Sep 8, 2010 at 6:25 PM, felix feli...@gmail.com wrote:
in the Names strawman, private foo at the top level has the same problem
as use strict at the top level. maybe there should be a general way of
delimiting a top-level lexical scope, so that pasting js together is still
relatively
2010/9/8 Dean Landolt d...@deanlandolt.com:
On Wed, Sep 8, 2010 at 6:25 PM, felix feli...@gmail.com wrote:
in the Names strawman, private foo at the top level has the same problem
as use strict at the top level. maybe there should be a general way of
delimiting a top-level lexical scope,
On Sep 8, 2010, at 3:25 PM, felix wrote:
in the Names strawman, private foo at the top level has the same problem as
use strict at the top level. maybe there should be a general way of
delimiting a top-level lexical scope, so that pasting js together is still
relatively easy?
Today,
Until JSLint actually enforces ES5 strict mode, its docs should not be
promoting use strict.
In the SVG past, the dark ages so to speak, some popular tools generated
invalid SVG-in-XML, and so did hand-coding authors. This begat missing xmlns=
declaration error correction. Same story as HTML
On 9/8/10 17:25, Brendan Eich wrote:
On Sep 8, 2010, at 3:25 PM, felix wrote:
in the Names strawman, private foo at the top level has the same problem as use
strict at the top level. maybe there should be a general way of delimiting a top-level
lexical scope, so that pasting js together is
On Sep 8, 2010, at 6:34 PM, felix wrote:
On 9/8/10 17:25, Brendan Eich wrote:
On Sep 8, 2010, at 3:25 PM, felix wrote:
in the Names strawman, private foo at the top level has the same problem
as use strict at the top level. maybe there should be a general way of
delimiting a top-level
On 9/8/10 18:52, Brendan Eich wrote:
There's no easy way to support concatenation and use strict (or private x). But the
ease of concatenative programming in JS is an illusion already. Accumulating properties
in the global object is a constant source of bugs and confusion. Modern JS libraries
On 9/8/10 19:08, felix wrote:
On 9/8/10 18:52, Brendan Eich wrote:
There's no easy way to support concatenation and use strict (or
private x). But the ease of concatenative programming in JS is an
illusion already. Accumulating properties in the global object is a
constant source of bugs and
I recently asked Kris Kowal what he recommends as the simplest way to write
simple JS modules today that can be used either as browser-side scripts or
as CommonJS modules. Adapting the elegant pattern he showed me, I suggest
the following variation:
foo.js
---
25 matches
Mail list logo
