On Tue, May 21, 2013 at 9:20 PM, Ron Buckton rbuck...@chronicles.org wrote:
What if the default Map prototype had a configurable but non-writable data
property for a @@coerceKey symbol that pointed to a default coercion
function. You could subclass Map and provide your own @@coerceKey
On May 21, 2013, at 6:42 PM, Tab Atkins Jr. wrote:
On Tue, May 21, 2013 at 4:19 AM, Brendan Eich bren...@mozilla.com wrote:
David Bruant wrote:
This description (arbitrary string keys, bidirectional link with style
rule) suggests that you want a proxy (canonical values are in the style
On May 22, 2013, at 5:20 AM, Ron Buckton wrote:
What if the default Map prototype had a configurable but non-writable data
property for a @@coerceKey symbol that pointed to a default coercion
function. You could subclass Map and provide your own @@coerceKey
implementation. Then
2013/5/21 Brendan Eich bren...@mozilla.com
David Bruant wrote:
This description (arbitrary string keys, bidirectional link with style
rule) suggests that you want a proxy (canonical values are in the style
rule, the proxy is just a façade with a bit of validation/coercion logic).
That's the
2013/5/21 Andreas Rossberg rossb...@google.com
What's your definition of entirely transparent then? Or in other
words, what if I use 'promise' outside a when?
I clarified this with Andreas in person, but FTR: entirely transparent is
indeed the wrong word to describe E promises.
For context,
On 18 May 2013 09:12, David Herman dher...@mozilla.com wrote:
On May 15, 2013, at 10:42 AM, Andreas Rossberg rossb...@google.com wrote:
(1) Change the set-up of .ondemand calls.
(2) Change the invocation of your bundling tool.
As soon as you have to go there, you've lost almost all
On 21 May 2013 03:41, David Herman dher...@mozilla.com wrote:
On May 9, 2013, at 6:30 AM, Andreas Rossberg rossb...@google.com wrote:
In your scheme, I honestly cannot tell. Which ones are absolute
logical module names, which ones are relative logical module names,
and which ones are relative
On Wed, May 22, 2013 at 11:27 AM, Andreas Rossberg rossb...@google.com wrote:
On 21 May 2013 03:41, David Herman dher...@mozilla.com wrote:
On May 9, 2013, at 6:30 AM, Andreas Rossberg rossb...@google.com wrote:
In your scheme, I honestly cannot tell. Which ones are absolute
logical module
Tab Atkins Jr. wrote:
On Tue, May 21, 2013 at 4:19 AM, Brendan Eichbren...@mozilla.com wrote:
So Tab: why do you want to abuse Map instead of make a custom class?
Restating from my earlier post:
1. when someone asks is this Map-like? in an appropriately idiomatic
JS way, they get a yes
On 22 May 2013 12:31, Sam Tobin-Hochstadt sa...@ccs.neu.edu wrote:
On Wed, May 22, 2013 at 11:27 AM, Andreas Rossberg rossb...@google.com
wrote:
On 21 May 2013 03:41, David Herman dher...@mozilla.com wrote:
But really, there was no real need for loading directly from a URL in the
first
Tab Atkins Jr. wrote:
If TC39 isn't going to allow us to ever use*any* of the built-in
collection classes just because we have type restrictions we need to
enforce, that'll be a pretty raw deal for authors.
Whining about TC39 like this is bad for business. Should I whine about
W3C to even up
2013/5/21 David Bruant bruan...@gmail.com
Would it make sense to add specific traps for specific objects (Date would
have some specific traps, so would objects with [[MapData]], so would
objects with [[SetData]], etc.)?
Very much like functions currently have some traps that only apply to
Andreas Rossberg wrote:
I suppose you are right for ondemand, but it doesn't apply to the
configuring the loader to accept URL's case Dave was alluding to,
right?
Finally I believe I've caught up and can jump in and answer: right!
(Bracing for impact!)
However, the other way than ondemand
On 22 May 2013 12:55, Brendan Eich bren...@mozilla.com wrote:
Andreas Rossberg wrote:
I suppose you are right for ondemand, but it doesn't apply to the
configuring the loader to accept URL's case Dave was alluding to,
right?
Finally I believe I've caught up and can jump in and answer:
On Wed, May 22, 2013 at 3:40 AM, Brendan Eich bren...@mozilla.com wrote:
There aren't many Map methods. Write your own workalikes if you need 'em.
Done.
Really? You're seriously saying that I, and every other spec author,
every time we need to spec something that's just like a built-in
On Wed, May 22, 2013 at 3:44 AM, Brendan Eich bren...@mozilla.com wrote:
Tab Atkins Jr. wrote:
If TC39 isn't going to allow us to ever use*any* of the built-in
collection classes just because we have type restrictions we need to
enforce, that'll be a pretty raw deal for authors.
Whining
On May 22, 2013, at 4:58 PM, Tab Atkins Jr. jackalm...@gmail.com wrote:
On Wed, May 22, 2013 at 3:40 AM, Brendan Eich bren...@mozilla.com wrote:
There aren't many Map methods. Write your own workalikes if you need 'em.
Done.
Really? You're seriously saying that I, and every other spec
On May 22, 2013, at 5:10 PM, Tab Atkins Jr. jackalm...@gmail.com wrote:
On Wed, May 22, 2013 at 3:44 AM, Brendan Eich bren...@mozilla.com wrote:
Tab Atkins Jr. wrote:
If TC39 isn't going to allow us to ever use*any* of the built-in
collection classes just because we have type restrictions
On Wed, May 22, 2013 at 9:44 AM, Brendan Eich bren...@mozilla.com wrote:
NodeList extends Array now but is not literally Array plus hooks. Same for
Map and the quite different thing you're specifying.
NodeList is an interesting case, actually. It's an Array, but with a
type restriction. Live
From: Tab Atkins Jr. [jackalm...@gmail.com]
NodeList is an interesting case, actually. It's an Array, but with a type
restriction.
What do you mean by that? Surely you don't mean can only store nodes:
```
var nodeList = document.querySelectorAll(div);
undefined
nodeList.length
22
Le 22/05/2013 19:02, Tab Atkins Jr. a écrit :
On Wed, May 22, 2013 at 9:44 AM, Brendan Eich bren...@mozilla.com wrote:
NodeList extends Array now but is not literally Array plus hooks. Same for Map
and the quite different thing you're specifying.
NodeList is an interesting case, actually.
is simply static collection, so immutable:
```
var all = document.querySelectorAll(*);
var length = all.length;
all[length] = 'whatever';
alert(all.length === length);
[].push.call(all, 'whatever');
alert(all.length === length);
```
you can put properties because is extensible but you won't
I believe Tab is asking for something like:
`var MyNodeList = new ArrayType(EntryType, length);`
where `EntryType` is his own type and the result is an array like
collection or map.
At least, for what I understood, looks like he's asking for JS CTypes,
something rumored a while ago but never
On Wed, May 22, 2013 at 10:35 AM, David Bruant bruan...@gmail.com wrote:
Le 22/05/2013 19:02, Tab Atkins Jr. a écrit :
On Wed, May 22, 2013 at 9:44 AM, Brendan Eich bren...@mozilla.com wrote:
NodeList extends Array now but is not literally Array plus hooks. Same
for Map and the quite
On Wed, May 22, 2013 at 11:00 AM, Andrea Giammarchi
andrea.giammar...@gmail.com wrote:
I believe Tab is asking for something like:
`var MyNodeList = new ArrayType(EntryType, length);`
where `EntryType` is his own type and the result is an array like collection
or map.
At least, for what I
On Wed, May 22, 2013 at 1:48 AM, Allen Wirfs-Brock
al...@wirfs-brock.com wrote:
On May 21, 2013, at 6:42 PM, Tab Atkins Jr. wrote:
On Tue, May 21, 2013 at 4:19 AM, Brendan Eich bren...@mozilla.com wrote:
David Bruant wrote:
This description (arbitrary string keys, bidirectional link with style
you wrote:
What do I need to do to get a Map like that?
I answered but I've mistaken your original question and apologized already.
regards
On Wed, May 22, 2013 at 11:10 AM, Tab Atkins Jr. jackalm...@gmail.comwrote:
On Wed, May 22, 2013 at 11:00 AM, Andrea Giammarchi
On Wed, May 22, 2013 at 3:43 PM, Allen Wirfs-Brock
al...@wirfs-brock.com wrote:
On May 22, 2013, at 7:21 PM, Tab Atkins Jr. wrote:
-ride the same number of @@ methods so I don't see a major gain in that
approach.
[[MapData]] is just a list of tuples. All I need for my spec (and for
future
Hello,
It's very likely it was (should have been I believe) discussed before, and
even probably was approved, but I don't see it in the latest draft yet.
Just to make sure, the signature of the assign and mixin method should
be:
Object.assign(target, source,[source2, ..., sourceN]);
On Wed, May 22, 2013 at 7:48 PM, Dmitry Soshnikov
dmitry.soshni...@gmail.com wrote:
Hello,
It's very likely it was (should have been I believe) discussed before, and
even probably was approved, but I don't see it in the latest draft yet.
The following has been discussed, but...
Just to
On Wed, May 22, 2013 at 5:53 PM, Rick Waldron waldron.r...@gmail.comwrote:
On Wed, May 22, 2013 at 7:48 PM, Dmitry Soshnikov
dmitry.soshni...@gmail.com wrote:
Hello,
It's very likely it was (should have been I believe) discussed before,
and even probably was approved, but I don't see
I found it [a fun exercise](https://gist.github.com/domenic/5632079) to show
how little code it takes to build unabashed monadic promises on top of Q-like
promises. (It's been a while since I exercised those brain-muscles, so any
corrections appreciated.) The punch line is
```js
function
On Wed, May 22, 2013 at 9:00 PM, Dmitry Soshnikov
dmitry.soshni...@gmail.com wrote:
On Wed, May 22, 2013 at 5:53 PM, Rick Waldron waldron.r...@gmail.comwrote:
On Wed, May 22, 2013 at 7:48 PM, Dmitry Soshnikov
dmitry.soshni...@gmail.com wrote:
Hello,
It's very likely it was (should
Sorry, I didn't get it. Could you show an example of how it's potentially
can be used, I'm curious. If there is no practical need for this -- of
course it matters whether it worth or not.
Since the spec is not approve yet, and particularly that section on assign
and mixin, it's exactly now a good
I think `[mixin1, mixin2, mixin3].reduce(Object.mixin, source);` is a win,
only thing I am not sure, is how this third argument could make into this
approach (if reusable, I didn't even know about this extra arg)
Any hint on the extra arg appreciated for polyfill purpose, thanks
On Wed, May 22,
On Wed, May 22, 2013 at 9:10 PM, Dmitry Soshnikov
dmitry.soshni...@gmail.com wrote:
Sorry, I didn't get it. Could you show an example of how it's potentially
can be used, I'm curious. If there is no practical need for this -- of
course it matters whether it worth or not.
Since the spec is
Please hold on with pollyfilling, until we realize this is something is
really required and can be useful. If it's not, this should be changed to
multiple arguments. Since this potential map is not even in current
draft, I believe Rick refers to something that was never taken as a real
thing to
I never hold on on polyfills, I already use Object.mixin in redefine.js and
other personal code ;-)
I think the direction is that second argument to N extra is an old pattern
TC39 won't lie for any new API
On Wed, May 22, 2013 at 6:18 PM, Dmitry Soshnikov
dmitry.soshni...@gmail.com wrote:
TC39 won't lie = TC39 won't like
On Wed, May 22, 2013 at 6:22 PM, Andrea Giammarchi
andrea.giammar...@gmail.com wrote:
I never hold on on polyfills, I already use Object.mixin in redefine.js
and other personal code ;-)
I think the direction is that second argument to N extra is an old
OK. Sorry, you still haven't convinced me yet.
Could someone from the committee explain me the real reasons please? If I
see them, I'm OK with having only one source. If there are good reasons, I
think we should use multiple sources with all advantages, which includes
also reflecting current libs
OK, I had feeling that I already asked this before, and it is true, more
than half and year ago:
https://mail.mozilla.org/pipermail/es-discuss/2012-October/025929.html.
This is why I was under impression that it was accepted and the methods
should use multiple args. I completely forgot about it.
Sorry but
`class B extends Object.mixing(Mixin1, Mixin2, Mixin3...)`
does not make sense to me ... would you mind explaining that ?
I am curious about this need to have more args there since nowadays there
are many ways to simulate that and `String.fromCharCode`, as example,
demonstrated
The particular example with `extends` doesn't matter much. What I manna do
is those function out of the box to be able to extend an object with
multiple objects at once. The example with class extends was just a recent
practical use-case after Allen said no mixins for classes.
If (for whatever
On Wed, May 22, 2013 at 6:04 PM, Domenic Denicola
dome...@domenicdenicola.com wrote:
I found it [a fun exercise](https://gist.github.com/domenic/5632079) to show
how little code it takes to build unabashed monadic promises on top of Q-like
promises. (It's been a while since I exercised those
From: Tab Atkins Jr. [mailto:jackalm...@gmail.com]
Thoughts?
Sounds like a great user-space library!!
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Tab’s proposal as I understand it is to standardize Q-like promises and add
a chain method that is then but with behavior tailored for monadic
composition.
This sounds like a good compromise.
The only downside I can contrive is that it gives users, particularly
novices, a subtle choice. Would it
It also adds a fulfill method. Thus, it presents two interfaces to the user:
fulfill + chain (aka unit + bind), and Q + then (aka resolve + then). This
seems to squarely fall into the trap Mark described in his original post, viz.
The main failure mode of standards bodies is to resolve a
47 matches
Mail list logo
