On Nov 20, 2011, at 8:30 PM, Brendan Eich wrote:
On Nov 20, 2011, at 1:18 PM, David Herman wrote:
I would not add more implicit magic to JS. E4X had junk like this in it,
which only ever concealed bugs.
I'm of two minds about this. In the abstract, I agree with Brendan;
fail-soft
On Nov 21, 2011, at 8:49 AM, Allen Wirfs-Brock wrote:
On Nov 20, 2011, at 8:30 PM, Brendan Eich wrote:
On Nov 20, 2011, at 1:18 PM, David Herman wrote:
I would not add more implicit magic to JS. E4X had junk like this in it,
which only ever concealed bugs.
I'm of two minds about this.
On Nov 20, 2011, at 8:30 PM, Brendan Eich wrote:
On Nov 20, 2011, at 1:18 PM, David Herman wrote:
I would not add more implicit magic to JS. E4X had junk like this in it,
which only ever concealed bugs.
I'm of two minds about this. In the abstract, I agree with Brendan;
fail-soft
On Nov 19, 2011, at 11:38 AM, Dean Landolt wrote:
On Sat, Nov 19, 2011 at 1:57 PM, Allen Wirfs-Brock al...@wirfs-brock.com
wrote:
On Nov 15, 2011, at 10:27 PM, Russell Leggett wrote:
but given the overall disapproval of the exact syntax of the | operator, I
think its at
On Nov 21, 2011, at 9:52 AM, Allen Wirfs-Brock wrote:
On Nov 20, 2011, at 8:30 PM, Brendan Eich wrote:
On Nov 20, 2011, at 1:18 PM, David Herman wrote:
I would not add more implicit magic to JS. E4X had junk like this in it,
which only ever concealed bugs.
I'm of two minds about this.
As promised, more verbose feedback for the Globalization API. My general
feeling is that the API is overly verbose for what it's doing. I'll
state my bias up front: I'm not a fan of introducing a bunch of new
types to handle formatting. I'd much rather have additional methods that
perform
At last week's TC39 meeting, I asked which error objects an API should throw
when it expects a string matching a specific pattern, but receives a string
that doesn't match the pattern. Examples in the Globalization API are language
tags, as defined in RFC 5646, or selectors such as sort and
Recently Claus Reinke proposed some alternative that I think feels is so much
more natural and simpler than | or beget:
Instead of this:
foo | { bar: 'bar' }
prototype can be a special property:
{ prototype: foo, bar: 'bar' }
simple and easy, of course it can have a different name from
On Nov 21, 2011, at 5:55 PM, Irakli Gozalishvili wrote:
Recently Claus Reinke proposed some alternative that I think feels is so much
more natural and simpler than | or beget:
Instead of this:
foo | { bar: 'bar' }
prototype can be a special property:
{ prototype: foo, bar: 'bar' }
9 matches
Mail list logo
