On Tue, Sep 7, 2010 at 9:35 PM, Brendan Eich bren...@mozilla.com wrote:
On Sep 7, 2010, at 10:28 AM, Boris Zbarsky wrote:
On 9/7/10 1:21 PM, Brendan Eich wrote:
See, e.g., https://bugzilla.mozilla.org/show_bug.cgi?id=593963 -- but
this is not the first instance. Previously:
There's no mistake that dedicated syntax for traits would help users and
implementors alike. However, while I (or others) could definitely come up
with a 'traits-as-sugar', or even a 'traits-as-a-new-value' proposal, that
still wouldn't solve the version evolution problem associated with trait
On 2010-09-09, at 06:13, Tom Van Cutsem wrote:
There's no mistake that dedicated syntax for traits would help users and
implementors alike. However, while I (or others) could definitely come up
with a 'traits-as-sugar', or even a 'traits-as-a-new-value' proposal, that
still wouldn't solve the
On Sep 9, 2010, at 1:09 AM, Dmitry Soshnikov wrote:
Thus the site's combined file won't be globally strict, however since a lib
is tested before a production release (at least I hope so ;), then the lib's
code should pass the strictness, and therefore, a use strict may be even
removed from
On Thu, Sep 9, 2010 at 10:32 AM, Brendan Eich bren...@mozilla.com wrote:
On Sep 9, 2010, at 1:09 AM, Dmitry Soshnikov wrote:
Thus the site's combined file won't be globally strict, however since a
lib is tested before a production release (at least I hope so ;), then the
lib's code should
On Sep 9, 2010, at 8:46 AM, Dean Landolt wrote:
On Thu, Sep 9, 2010 at 10:32 AM, Brendan Eich bren...@mozilla.com wrote:
On Sep 9, 2010, at 1:09 AM, Dmitry Soshnikov wrote:
Thus the site's combined file won't be globally strict, however since a lib
is tested before a production release
On Thu, Sep 9, 2010 at 1:09 AM, Dmitry Soshnikov
dmitry.soshni...@gmail.com wrote:
Currently, a site may normally concatenate 3rd-party libs with use strict
at the global level. The technique is the same as with forgotten semicolon
-- just to put an empty statement at the beginning of the end
2010/9/9 Dmitry Soshnikov dmitry.soshni...@gmail.com:
On Tue, Sep 7, 2010 at 9:35 PM, Brendan Eich bren...@mozilla.com wrote:
On Sep 7, 2010, at 10:28 AM, Boris Zbarsky wrote:
On 9/7/10 1:21 PM, Brendan Eich wrote:
See, e.g., https://bugzilla.mozilla.org/show_bug.cgi?id=593963 -- but
On Thu, Sep 9, 2010 at 6:32 PM, Brendan Eich bren...@mozilla.com wrote:
On Sep 9, 2010, at 1:09 AM, Dmitry Soshnikov wrote:
Thus the site's combined file won't be globally strict, however since a
lib is tested before a production release (at least I hope so ;), then the
lib's code should
On Thu, Sep 9, 2010 at 07:08, Tom Van Cutsem tomvc...@gmail.com wrote:
Both of these seem to be compelling advantages of soft fields over names.
However, I wonder if it would be possible to get the best of both worlds.
IIUC, the Names proposal converts:
private x;
this.x = foo;
this.x
On Sep 9, 2010, at 10:33 AM, Dmitry Soshnikov wrote:
On Thu, Sep 9, 2010 at 6:32 PM, Brendan Eich bren...@mozilla.com wrote:
On Sep 9, 2010, at 1:09 AM, Dmitry Soshnikov wrote:
Thus the site's combined file won't be globally strict, however since a lib
is tested before a production
On Thu, Sep 9, 2010 at 9:35 PM, Brendan Eich bren...@mozilla.com wrote:
On Sep 9, 2010, at 10:33 AM, Dmitry Soshnikov wrote:
On Thu, Sep 9, 2010 at 6:32 PM, Brendan Eich bren...@mozilla.com wrote:
On Sep 9, 2010, at 1:09 AM, Dmitry Soshnikov wrote:
Thus the site's combined file won't be
On Sep 9, 2010, at 11:57 AM, Dmitry Soshnikov wrote:
But that exactly I proposed -- to insert into the combined file an /empty
statement/ _before_ the first part.
Right. There's a rule, Dojo follows it IIRC, to prepend ; to all files, always.
That will do the trick.
But of course people
On Sun, Sep 5, 2010 at 6:33 PM, Mark S. Miller erig...@google.com wrote:
http://wiki.ecmascript.org/doku.php?id=strawman:classes_as_sugar
* Classes as Sugar
All this looks a bit strange. From several positions.
First, combination of classes and prototypes. Currently, the paradigm used
in
As Brendan pointed out, the version evolution problem is nowhere near
a solved issue in language design; the only approaches I know of that
get close to it are the versioning of words in Forth and, depending on
how you look at it, the dynamic code loading mechanisms of Erlang
(and class loaders in
On Thu, Sep 9, 2010 at 10:37 PM, Brendan Eich bren...@mozilla.com wrote:
On Sep 9, 2010, at 3:06 PM, Dirk Pranke wrote:
As Brendan pointed out, the version evolution problem is nowhere near
a solved issue in language design; the only approaches I know of that
get close to it are the
On Thu, Sep 9, 2010 at 10:37 PM, Brendan Eich bren...@mozilla.com wrote:
On Sep 9, 2010, at 3:06 PM, Dirk Pranke wrote:
As Brendan pointed out, the version evolution problem is nowhere near
a solved issue in language design; the only approaches I know of that
get close to it are the
Also, the duality of Object.create vs Traits.create accommodates traditional
vs high integrity quite well -- without AFAICT compromising either.
It creates a false choice, though (all or nothing). IIUC, with Object.create,
you don't even get the conflict checking. And then you've really lost
On Sep 9, 2010, at 4:06 PM, Mark S. Miller wrote:
1. It's premature to standardize something so new. Again, the Array extras
(map, filter, etc.) have been a de-facto standard for years, getters and
setters for over a decade, bind-like library methods and JSON for quite a
long while.
2.
On Thu, Sep 9, 2010 at 11:31 PM, David Herman dher...@mozilla.com wrote:
Also, the duality of Object.create vs Traits.create accommodates
traditional vs high integrity quite well -- without AFAICT compromising
either.
It creates a false choice, though (all or nothing).
It does create a
On Fri, Sep 10, 2010 at 5:30 AM, David Herman dher...@mozilla.com wrote:
IIUC, with Object.create, you don't even get the conflict checking. And
then you've really lost the key benefit of traits.
See
http://code.google.com/p/es-lab/source/browse/trunk/src/traits/traits.js#150.
Even with
21 matches
Mail list logo
