Fully agree on all counts.
Dave
--
Sent from my Android phone with K-9 Mail. Please excuse my brevity.
Brendan Eich wrote:
On Apr 2, 2011, at 4:33 PM, David Herman wrote: > (We've talked a little bit
about generalizing the `require' form to be an expression operator that does a
static module
On Apr 2, 2011, at 4:33 PM, David Herman wrote:
> (We've talked a little bit about generalizing the `require' form to be an
> expression operator that does a static module load, but I'm not sure whether
> it hangs together.)
I don't see how we can reserve 'require' as a static (compile-time)
p
On Apr 2, 2011, at 4:19 PM, David Bruant wrote:
> I have the feeling that none of these can help out with multiple inheritance.
> This is the problem I want to address.
Why? I mean, given the WebIDL and DOM changes.
> Is multiple inheritance a use case that TC39 intends to address in a generic
> Also, is it currently specified if rest parameters can have default
> values?
I'm more skeptical of this one. It's sort of treating empty arrays as falsey,
which they aren't. And I've never noticed a need for this. But that might just
be the BLUB principle in action. Do you have examples/use c
Hi Sean,
Yes, I'm interested in this possibility as well. It'll probably take some
careful working-through of the details to figure out exactly when/where this is
doable, but it's on my radar.
Thanks,
Dave
On Apr 1, 2011, at 7:37 AM, Sean Eagan wrote:
> Why not allow the spread operator to ap
Hi James,
> 1) Files as modules do not need module wrapper
>
> Just to confirm, if a JS file contains only a module definition, the
> module X{} wrapper is not needed?
That's correct.
>
> 2) Set module export value
>
>
> Is it possible to support settin
Le 02/04/2011 23:40, Brendan Eich a écrit :
> On Apr 2, 2011, at 1:58 PM, David Bruant wrote:
>
>> I'm surprised by the idea that == could be defined on a per-value
>> comparison basis on objects (Array as you give it as an example). It
>> doesn't make the relation last throughout the program lifet
On Apr 2, 2011, at 1:58 PM, David Bruant wrote:
> I'm surprised by the idea that == could be defined on a per-value
> comparison basis on objects (Array as you give it as an example). It
> doesn't make the relation last throughout the program lifetime (which is
> what I was trying to do and requir
On Apr 2, 2011, at 1:58 PM, David Bruant wrote:
> I'm surprised by the idea that == could be defined on a per-value
> comparison basis on objects (Array as you give it as an example). It
> doesn't make the relation last throughout the program lifetime (which is
> what I was trying to do and requir
Le 02/04/2011 21:30, Brendan Eich a écrit :
> On Apr 2, 2011, at 12:16 PM, Brendan Eich wrote:
>
>> You must mean only in the cases where typeof a == typeof b, then a == b <=>
>> a === b, and === is an e.r. But that does not mean == is an e.r.
> Forgot typeof a == "object" above, to be precise.
In
[Adding DOMCore to the discussion]
Le 02/04/2011 21:16, Brendan Eich a écrit :
> On Apr 2, 2011, at 11:44 AM, David Bruant wrote:
>
>> Hi,
>>
>> This proposal is another attempt to address the DOM Element+EventTarget
>> multiple inheritance issue in ECMAScript.
>
> That issue was resolved by putti
On Apr 2, 2011, at 12:16 PM, Brendan Eich wrote:
> You must mean only in the cases where typeof a == typeof b, then a == b <=> a
> === b, and === is an e.r. But that does not mean == is an e.r.
Forgot typeof a == "object" above, to be precise.
> For mismatching types, == is not transitive, so
On Apr 2, 2011, at 11:44 AM, David Bruant wrote:
> Hi,
>
> This proposal is another attempt to address the DOM Element+EventTarget
> multiple inheritance issue in ECMAScript.
That issue was resolved by putting EventTarget on the inheritance chain. See
http://dvcs.w3.org/hg/domcore/raw-file/tip/
Hi,
This proposal is another attempt to address the DOM Element+EventTarget
multiple inheritance issue in ECMAScript.
The main idea of my proposal is to introduce the concept of "object
equivalence classes". First off, I'd like to say that I refer to a
concept (http://en.wikipedia.org/wiki/Equiva
14 matches
Mail list logo
