Re: stable sort proposal

[Dean Landolt]

Why should you have to opt into to stable sort? Why not the other way
around? `Array.prototype.fastestSort` or some such -- or better yet, spec a
symbol for it that falls back to `Array.prototype.sort` for implementations
that don't expose a faster unstable variety.

On Thu, Mar 17, 2016 at 7:35 PM, Isiah Meadows 
wrote:

> How about an `Array.prototype.stableSort(comparator?)` method? Several
> languages already have something like this, anyways.
>
> (Speaking of bugs related to unstable sorts, my blog has that problem as
> well - unstable sort resulting in incorrect order.)
>
> On Wed, Mar 16, 2016, 18:50 Tab Atkins Jr.  wrote:
>
>> On Tue, Mar 15, 2016 at 8:50 AM, Vic9  wrote:
>> >> What about the Timsort?
>> >
>> > I cannot believe it will be faster on random int array. And TimSort is
>> base on MergeSort and, seems, for it's worst cases it cannot be better than
>> MergeSort.
>> > I have tried https://github.com/mziccard/node-timsort/ with my old
>> node.js - 0.10.4 and Chrome 49 (win32) - and I see that random int array
>> case is much slower that native in Chrome, and in node.js too if I replace
>> "native" with a function from
>> https://github.com/v8/v8/blob/master/src/js/array.js .
>> >
>> > Perhaps, implementers will want to leave the behaviour of
>> `array.sort(comparefn)` as it was for backward compatiblity.
>>
>> There's no back-compat impact for switching to a stable sort; since
>> you can't depend on the ordering of an unstable sort in the first
>> place, changing that order (to stable) is fine.  (Most likely it'll
>> *fix* pages that are currently sometimes broken in small ways because
>> they assume stability.)  It's just potentially a minor speed drop.
>>
>> ~TJ
>> ___
>> es-discuss mailing list
>> es-discuss@mozilla.org
>> https://mail.mozilla.org/listinfo/es-discuss
>>
>
> ___
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: stable sort proposal

[Dean Landolt]

On Tue, Mar 15, 2016 at 12:00 AM, Vic9  wrote:

> @Tab Atkins Jr.,
>
> The only question is how much slower/more expensiver stable sorting is
> than unstable sorting, and whether that cost is sufficient to outweigh the
> usefulness of a stable sort.
> My own experiment shows, that QuickSort (unstable) is ~20% (or more)
> faster on "random" array of integers (a good case for QuickSort). Probably,
> there are many Chrome users who sort large integer arrays, and so Chrome
> devs will never switch to a stable sort. (see comments at
> https://bugs.chromium.org/p/v8/issues/detail?id=90 )
>


I bet the chrome team would switch it were spec'd that way -- this would
put them on an even playing field with other implementations. But yes, 20+%
definitely makes the case that if stable sort were spec'd, a hook to get to
at any faster unstable sort should be specified as well.

But again, unstable sort should be opt-in, used by those that fully grok
the implications. Devs who don't really know the difference (a *large*
proportion, IME) are very likely to expect stable sort semantics.
Correctness should trump performance for the default case.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: stable sort proposal

[Dean Landolt]

On Mon, Mar 14, 2016 at 2:16 PM, Tab Atkins Jr. 
wrote:

> On Fri, Mar 11, 2016 at 8:17 PM, Isiah Meadows 
> wrote:
> > In my honest opinion, there's not much reason to just require the sort
> to be
> > stable. Some engines have done this in the past, and the spec technically
> > allows it. At this point, stable sorts are about as fast as unstable
> ones,
> > both in theory and practice (wasn't the case 10 years ago IIRC).
>
> I think you meant "to not just require", yes?  As in, you think the
> spec *should* require .sort() to be stable?
>
> On Sun, Mar 13, 2016 at 12:23 PM, Vic9  wrote:
> > Stable sort is useful sometimes, but it is possible to implement it in
> js.
>
> Most things in the JS standard library are possible in userland code,
> so that's not a useful rebuttal to anything by itself.  The question
> is whether it's worth requiring that the standard sort be stable.
> Stable sort is never *bad* - there are no use-cases where a stable
> sort gives the wrong answer while an unstable sort is correct, but the
> opposite is definitely true.  The only question is how much
> slower/more expensiver stable sorting is than unstable sorting, and
> whether that cost is sufficient to outweigh the usefulness of a stable
> sort.
>

ISTM a symbol could be defined to grab a handle on the implementation's
fastest possible sort logic. If the implementation has a substantially
faster unstable sort algo they'd surface it here -- otherwise this would
just delegate to the implementation's stable sort. This could be
`Array.prototype.sort`, or it could also be a spec'd symbol which
`Array.prototype.sort` delegates to. (Or this could all be done w/ modules,
although modules might complicate what's otherwise pretty simple to
polyfill).

But fastest-possible (likely unstable) sort logic should be opt-in, not
opt-out. If the perf difference is that relevant to your use case you
probably don't want off-the-shelf `Array.prototype.sort` anyway.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Any reason why __proto__ is not a well known symbol?

[Dean Landolt]

On Tue, Feb 16, 2016 at 1:23 AM, Tab Atkins Jr. 
wrote:

> On Mon, Feb 15, 2016 at 9:14 PM, Coroutines  wrote:
> > On Mon, Feb 15, 2016 at 8:51 PM, Tab Atkins Jr. 
> wrote:
> >> It was specified before symbols existed, and all implementations do it
> >> as a string property.  If we were reinventing it today it would either
> >> be a symbol or something in the MOP, but are hands are tied by legacy.
> >>
> >>> Being that it was not formally spec'd it shouldn't have broke backwards
> >>> compatibility either.
> >>
> >> Backwards compat has nothing to do with specs, and everything to do
> >> with existing implementations.  Multiple implementations agreed on
> >> __proto__, so our choice was either to leave it unstandardized or spec
> >> what the browsers did.
> >
> > Is there a migration to make it a Symbol in ES7?  (ignorant question?)
>
> There's a lot of code in the wild that uses __proto__ and depends on
> it.  We can't remove it until/unless that changes (it won't, at least
> not in the near future), and while we have __proto__, there's no
> reason to have anything else.
>


Is it too late to remove support for dunder-__proto__ strictly within
module contexts? This might introduce a bit of a refactor hazard when
pulling old code into modules, but it's only the static `obj.__proto__`
usage that has any effect so this can be handled pretty easily with linter
warnings. Or it could be contextually reserved and throw an early exception.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Re: Just try

[Dean Landolt]

On Fri, Oct 30, 2015 at 2:17 PM, Alican Çubukçuoğlu <
alicancubukcuo...@gmail.com> wrote:

> The recommended way of checking for file existence in Node.js is calling
> `fs.stat()` on the file. If no error was passed to the callback, it exists.
> If "ENOENT" was passed, it doesn't.
>
> If you "promisify" `fs.stat()` and use it with async/await, it throws when
> a file doesn't exist so you end up writing a lot of try/catches. You say
> "Hey, it would be great if I didn't have to keep writing `catch(e){}`." but
> what if the error wasn't "ENOENT"?
>
> That's why I withdrew myself from suggesting such a thing. Carelessly
> silencing errors is no good.
>
> I like the idea of `let stuff = try something()` putting the error in
> `stuff` but the problem is you can throw strings in JavaScript:
>
> ```
> function getUserName() {
>   throw 'Error';
> }
>
> const userName = try getUserName();
>
> if (userName instanceof Error) {
>   handleError(userName);
>
>   return;
> }
>
> console.log('There was no error, yay!');
> // Actually there was
>


I think you missed the tuple destructuring in the example try-expression.
It wasn't:

```js
let errOrValue = try JSON.parse('invalid');
```

But instead:

```js
let [err, result] = try JSON.parse('invalid');
```

This avoids the problem you noted, and actually, plays nice w/ node's
error-first callbacks:

```js
cb.apply(null, try JSON.parse('invalid'));
```
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Exporting Symbols

[Dean Landolt]

The symbol registry is a great way to map universal (not just global, but
fully cross-realm) names (strings) to unique, distinct concepts (symbols).
But as a flat string namespace has all the same kinds of issues symbols
were introduced to solve. IIUC throwing `Math.random` strings into the
symbol registry is pretty much equivalent to writing (non-enumerable)
Math.random object properties on the global object, right? Doesn't this
eliminate any of the cross-realm dereferencing advantages provided by the
symbol registry?

I suspect we'll see the symbol registry used with something like xml's
namespace uris to address this -- fully qualified, canonical uris as a
means of unambiguously resolving the symbol for some fully-cross-realm
"concept", which might look something like `Symbol.for('
http://example.com/v5.4')` .

This mitigates collisions naturally, and is reasonably legible -- though
I'm devs won't want to pepper these xmlns monstrosities throughout their
application code. ISTM library authors will end up providing something like
the `require(“our-symbols”).SpecialSymbol` module Fransisco suggested,
where string binding names, sensible in the context of some library, are
associated with these global fully-qualified registered symbols.

This might look `export let v5_4 = Symbol.for('http://example.com/v5.4')
}`. The url can be whatever you want (and like xmlns uris, need not be
resolvable). There are certainly better uri schemes for this that may be
more sensible -- you can use whatever you want, so long as you do it
consistently. This essentially transform the module import path namespace
into a kind of thesaurus to map strings which make sense in the context of
some module to some universal concept -- which could offer some pretty nice
wins when writing generic library code.


On Thu, Oct 15, 2015 at 4:28 PM, Rick Waldron 
wrote:

> The math.trunc part is completely irrelevant, leftover from fiddling
> around—sorry for the noise!
>
> On Thu, Oct 15, 2015 at 4:13 PM Rick Waldron 
> wrote:
>
>> Symbol has built-in API for making Symbols available across all code
>> realms:
>>
>> http://www.ecma-international.org/ecma-262/6.0/#sec-symbol.for
>> http://www.ecma-international.org/ecma-262/6.0/#sec-symbol.keyfor
>>
>>
>> You can create a generated key and export it, giving your consumers only
>> the key, which they can then use to get the symbol.
>>
>>   // In module.js
>>   let key = Math.trunc((Math.random() * 0x));
>>   let sym = Symbol.for(key);
>>   // use sym throughout the module code
>>   export { key as features }
>>
>>   // In program.js
>>   import { features } from "module";
>>
>>   console.log(features, Symbol.for(features));
>>
>>
>> Rick
>>
>>
>>
>>
>>
>> On Thu, Oct 15, 2015 at 3:38 PM Alexander Jones  wrote:
>>
>>> Unless of course you needed to export a "features" AND support this
>>> magic symbol.
>>>
>>> On Thursday, 15 October 2015, Ron Buckton 
>>> wrote:
>>>
 Wouldn’t this work?



 our-symbols.js:

 ```js

 export const SpecialSymbol = Symbol("SpecialSymbol");

 ```



 their-consumer.js

 ```js

 import { SpecialSymbol } from "our-symbols";



 export const features = {

 [SpecialSymbol]: true

 };

 ```



 our-features.js

 ```js

 import { SpecialSymbol } from "our-symbols";

 import { features } from "their-consumer";



 if (features[SpecialSymbol]) {

   // …

 }

 ```



 This uses an export named “features”, though in practice it’s pretty
 much the same as using “export default”. While the “features” identifier
 could theoretically be some other “features” with a different meaning, you
 can still detect the presence of your special symbol.



 Ron



 *From:* es-discuss [mailto:es-discuss-boun...@mozilla.org] *On Behalf
 Of *Francisco Tolmasky
 *Sent:* Thursday, October 15, 2015 10:47 AM
 *To:* Logan Smyth 
 *Cc:* es-discuss@mozilla.org
 *Subject:* Re: Exporting Symbols



 There are special features we want to expose if a module defines a
 certain key. However, we’d like to not rely on certain names just because
 there’s some chance they came up with it themselves. If it was a symbol
 that we gave them access to, it would be impossible for this to be the
 case, they would have had to grab the symbol from us:



 var SpecialSymbol = require(“our-symbols”).SpecialSymbol;



 export { whatever as SpecialSymbol }



 The difficulty I’m having right now is being torn by two competing
 “best practices”: on the one hand, you can’t do what I did above for the
 runtime reasons, on 

Re: Exporting Symbols

[Dean Landolt]

 [snip]


> So if you export an opaque identity that you created yourself, and don't
> expose some mechanism for downstream consumers to know what it means,
> you're handing a bag of meaningless tokens which are, by definition,
> completely useless to them.
>

I should add: if you only intend to default-export a *single* symbol, this
is not semantically meaningless. It may be possible to infer some kind of
meaning from the module path of the import. I'm not convinced this is
valuable, but it seems like something which could be made to work.

My point only holds when not doing a default-export of a symbol -- e.g.
using symbol keys on a default-exported object or using unregistered
symbols as export bindings (if this were even possible).
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Exporting Symbols

[Dean Landolt]

On Fri, Oct 16, 2015 at 3:46 PM, Rick Waldron <waldron.r...@gmail.com>
wrote:

>
>
> On Fri, Oct 16, 2015 at 2:47 PM Dean Landolt <d...@deanlandolt.com> wrote:
>
>> The symbol registry is a great way to map universal (not just global, but
>> fully cross-realm) names (strings) to unique, distinct concepts (symbols).
>> But as a flat string namespace has all the same kinds of issues symbols
>> were introduced to solve. IIUC throwing `Math.random` strings into the
>> symbol registry is pretty much equivalent to writing (non-enumerable)
>> Math.random object properties on the global object, right?
>>
>
> Global object is not cross-realm. Symbol registry is cross realm, try this
>
>   var iframe = document.createElement("iframe");
>   document.body.appendChild(iframe);
>   iframe.contentWindow.Symbol.iterator === Symbol.iterator; // true, this
> is in the Symbol registry.
>   iframe.contentWindow.Symbol === Symbol; // false
>   iframe.contentWindow.Array === Array; // false
>

I know -- I said that in the first line of my message :)

But if you register a random value as the key of a symbol, how would a
consumer resolve that key? They would have to get a reference to the
module, right? How would two different consumers, in two different realms,
resolve the same key? AFAIK they can't, at least not without additional
coordination. AFAIK this symbol would only be useful to users within a
single realm, which is why I suggested it was equivalent to tucking it on a
global somewhere.



> Also, the OP is actually asking to give away the Symbol key:
>
>   "There are special features we want to expose if a module defines a
> certain key. However, we’d like to not rely on certain names just because
> there’s some chance they came up with it themselves. If it was a symbol
> that we gave them access to, it would be impossible for this to be the
> case, they would have had to grab the symbol from us:
>
>   var SpecialSymbol = require(“our-symbols”).SpecialSymbol;
>
>   export { whatever as SpecialSymbol }"
>
>
> My example wasn't intended to show Francisco what I think he _should_ do,
> just to answer his question based on his expressed parameters.
>

Fair enough -- I wasn't trying to call out your answer specifically -- I
was just trying to point out the benefits using the symbol registry for
truly cross-realm coordination, and trying to expand a bit on what that can
look like.

Francisco's examples, from what I could tell at least, can't really be made
to work as is, even if you could export symbol bindings. The symbols being
exported are generated within the module itself, so without associating
them with some known semantics (one way or another), they're completely
opaque to downstream consumers. When default-exporting an object w/ symbol
keys, you can get a handle on all these symbols through reflection, but
they're still inherently indistinguishable from each other, and meaningless
in general. (Unless you switch on their string description -- but that's
madness!)

The solution you proposed does accomplish what he seems to be after -- but
I suppose I neglected to elaborate on why I believe what he's chasing is
fundamentally flawed...


> If it were me...
>
>   // module.js
>   let sym = Symbol();
>   // ...use my sym for special features...
>   export { sym as feature }
>
>
> Seems sufficient? Maybe I've misunderstood the constraints.
>

IIUC he wants to export multiple symbols from a given module, without
having to conjure up application-specific strings for each. But as soon as
you introduce objects with opaque identity (what a philosopher might call
"intensional objects") -- whether through Symbols, UUIDs, random values,
whatever -- you have to come up with some mechanism to communicate their
semantics. Otherwise they're completely useless, for identity purposes at
least. Unless they fail at being opaque -- but that's always a bug...

For example, Symbols themselves are beautifully opaque -- but if you try to
use the Symbol description string as a means to communicate semantics on a
symbol instance you break this property. Don't do that. It may seem as
though something like a UUIDv1, which exposes process identity and some
information about the processor's wallclock, isn't fully opaque. This
information can be used to partially order the creation date of UUIDs by
the process which generated them, but this says absolutely nothing about
what any of these UUIDs actually represent. From an identity standpoint,
they're still completely opaque.

So if you export an opaque identity that you created yourself, and don't
expose some mechanism for downstream consumers to know what it means,
you're handing a bag of meaningless tokens which are, by definition,
completely useless to them.

This problem of assigning semantics is

Re: Please help with writing spec for async JSON APIs

[Dean Landolt]

On Tue, Aug 4, 2015 at 9:53 AM, Mark Miller erig...@gmail.com wrote:

 +1 for line delimited JSON. It would be good to switch all users of
 json-seq over to it and to deprecate json-seq. Perhaps an RFC would help.


 On Mon, Aug 3, 2015 at 11:53 PM, Bruno Jouhier bjouh...@gmail.com wrote:

 RFC 7464 has a different format (0x1E at beginning of every record) and a
 different media type (application/json-seq vs application/x-ldjson) than
 line delimited JSON (https://en.wikipedia.org/wiki/Line_Delimited_JSON).
 The 0x1E at the beginning of every record makes it hard to edit these
 files.

 Not sure it will improve interoperability, rather fragment things because
 it is likely that most people will stick to ldjson.

 2015-08-04 1:29 GMT+02:00 Carsten Bormann c...@tzi.org:

 Hi Domenic,

 We have a spec for that: RFC 7464



 --
   Cheers,
   --MarkM

 ___
 es-discuss mailing list
 es-discuss@mozilla.org
 https://mail.mozilla.org/listinfo/es-discuss


FWIW there are very nice ways to encode stream-ready JSON such that its
perfectly backward compatible with `JSON.parse` but still approximately as
easy as line-delimited JSON. The whitespace within stringified JSON can be
given optional significance, essentially it can act as a stream chunk
delimiter hint. For example each element of a top level array on single
line -- essentially equivalent to line-delimited JSON with 1 additional
char per line, the comma. And its nearly as easy to parse -- it's only
added complexity is the fact that as this is a valid profile of JSON, it'd
be nice for parsers to validate syntax (really just trailing commas), but
this is not strictly necessary.

Top level arrays can be emitted as kv pairs per line, which allows for
elegant streaming over associative array types. This is also really easy to
parse and maintains backcompat w/ `JSON.parse`.

It would also be possible to introduce optional nesting sigils using more
whitespace, e.g. encoding chunk boundaries for two or more level nesting in
a way that would allow parsers to allow opt-in SAXisms to any arbitrary
level of nesting, but in a way that cleanly falls back to `JSON.parse`.

As a side benefit, the layout of these nesting sigils could be designed in
a way that makes it a lot easier to read than the extremely dense
`JSON.stringify` default behavior. As it happens, using leading whitespace
to indicate nesting would look a lot like pretty printing -- this wouldn't
be anything more than a pretty printer with some optional embedded
semantics attached.

Async encode and decode behavior can be layered on top of the `depth: 1`
serialization and deserialization. If you want more depth just add
recursion. If at any point you don't want streaming, just use `JSON.parse`.

I'm not sure something like this is strictly necessary in the language, but
if it is, ISTM it would be pretty low-footprint way to get it in -- it'd be
nice to avoid yet another format.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: await on synchronous functions

[Dean Landolt]

On Sun, Jul 26, 2015 at 8:07 AM, Benjamin Gruenbaum benjami...@gmail.com
wrote:

  Out of curiosity, can you give an example of the Not Good parts? ISTM
 the await prefix is more of an explicit cast than an implicit conversation,
 and other than the very small timing gap in how throws are handled I
 pointed out a few days ago, I can't think of any situations where a throw
 would make more sense than casting values to promises.

 Sure, lots of such cases exist today with promises and are easy to
 reproduce

 ```js
 async function foo {
 let result = await bar; // instead of bar();
 let result2 = await callbackFn(); // await on function that was not
 promisified yet, that is, it takes a callback
 let result3 = await [p1, p2, p3]; // people might expect a Promise.all
 on an array, but this doesn't actually wait for anything.
 }
 ```


The first example is a basic type error, not at all specific to promises or
async programming -- it could be made any number of ways. If you want to
call it a footgun, that's fine -- but ISTM the only real solution is use
TypeScript (or some analog).

I don't see how the last example could possibly exist today as it reflects
a hypothetical user's misunderstanding of `async/await` syntax
specifically. Perhaps there's a case to be made that there's a footgun here
(though I'd disagree), but it's beside the point of this thread.

But the second example, `await callbackFn()`, seems reasonable. I still
think it would be a shame to punt on otherwise elegant ergonomics just due
to this, but I buy that there's at least some benefit now.

I suppose it'd always be possible to introduce something like
`await.resolve` if there's demand for this kind of sync/async normalization.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: await on synchronous functions

[Dean Landolt]

On Thu, Jul 23, 2015 at 9:06 AM, Andreas Rossberg rossb...@google.com
wrote:

 On 17 July 2015 at 23:39, Mark S. Miller erig...@google.com wrote:

 On Fri, Jul 17, 2015 at 10:41 AM, Andrea Giammarchi 
 andrea.giammar...@gmail.com wrote:

 If I might, if there's one thing that has never particularly shone in
 JS, that is consistency.

 I see only two possibilities here: 1) it throws with non Promises 2) it
 Promisify anything that's not a Promise as if it was a
 `Promise.resolve(1)` ... but since there's too much magic in the second
 point, I'd rather stick with the first one.


 Definitely #2. Had #1 been proposed, async/await never would have
 achieved consensus.


 Wait, what?? Oh no, please don't bake that sloppy craze deeper into the
 language! Implicit conversions are Not Good.


Out of curiosity, can you give an example of the Not Good parts? ISTM the
`await` prefix is more of an explicit cast than an implicit conversation,
and other than the very small timing gap in how throws are handled I
pointed out a few days ago, I can't think of any situations where a throw
would make more sense than casting values to promises.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: await on synchronous functions

[Dean Landolt]

On Fri, Jul 17, 2015 at 6:54 PM, Andrea Giammarchi 
andrea.giammar...@gmail.com wrote:

 Meaning putting a Promise in a chain of promises is a point of no return
 so I've never seen/heard/imagined a case where you have a promise and
 suddenly you refactor that to be synchronous.



This is a great point, and I think makes a good argument against the
refactoring use case. But there are other plenty of other interesting use
cases (e.g. Bergi's IEAFE). Consistent sync/async resolution semantics
would allow you to write generic sync/async handlers, which comes up all
over the place.

This approach neatly cleans up some of the inconsistencies around handling
sync throws vs. rejections vs. *zalgo* throws (usually promise-returning
functions which throw before returning a promise). A try/catch around some
`await` will handle all three cases the same, almost -- there's one small
catch (w/ apologies for the bad pun)...

IIUC the behavior of `Promise.resolve` alone are insufficient to get
identical semantics between sync and async calls -- you'd need to spin the
event loop before rethrowing a sync exception, akin to the behavior of
bluebird's `Promise.try`. A minor detail, but punting on this would force
users into wrapping every call with something like `Promise.try`, which
seems like a shame. ISTM these `try` semantics, rather than
`Promise.resolve`, are more natural as the foundation for `await`.


The specific Promise gonna  Promise was actually mentioning another
 thread about cancelability and the fact Promises are Promises and  should
 just Promise :-)

 Sorry for the confusion

 On Fri, Jul 17, 2015 at 10:41 PM, Mark S. Miller erig...@google.com
 wrote:

 Hi Andrea, what do you mean by Promise must Promise? I've never seen
 this phrase before.


 On Fri, Jul 17, 2015 at 11:35 AM, Andrea Giammarchi 
 andrea.giammar...@gmail.com wrote:

  Think about a large program where you refactor a single async
 function to no longer be async

 did that ever happened in the history of logic? I am actually curious to
 understand a single valid case where that would be a solution to any
 problem.

 Apologies if I can't see your point but we've been talking about
 Promise must Promise so much this answer was absolutely unexpected.

 Thanks for any sort of clarification

 On Fri, Jul 17, 2015 at 7:27 PM, Tom Van Cutsem tomvc...@gmail.com
 wrote:

 2015-07-17 19:41 GMT+02:00 Andrea Giammarchi 
 andrea.giammar...@gmail.com:

 If I might, if there's one thing that has never particularly shone in
 JS, that is consistency.

 I see only two possibilities here: 1) it throws with non Promises 2)
 it Promisify anything that's not a Promise as if it was a
 `Promise.resolve(1)` ... but since there's too much magic in the second
 point, I'd rather stick with the first one.


 I would be highly in favor of (2). Think about a large program where
 you refactor a single async function to no longer be async. Then I see no
 reason why I should be forced to refactor all of its callers to remove the
 await keyword. Going from sync to async requires refactoring because you're
 introducing new potential interleaving hazards, but any code that is
 already prepared to work with async functions (or promises in general)
 should work equally fine on immediately resolved promises.

 regards,
 Tom




 Just my quick thoughts

 Best Regards

 On Fri, Jul 17, 2015 at 6:33 PM, Kevin Smith zenpars...@gmail.com
 wrote:

 I know the spec for this isn't finalized, but what is the current
 direction for the behaviour when await is used on a function that is not
 marked async and doesn't return a Promise? Should it run immediately or
 wait for the next turn of the event loop?


 More generally, the question is: what should await do for
 non-promises?

 await 1;

 Should it force a job to be queued?

 ___
 es-discuss mailing list
 es-discuss@mozilla.org
 https://mail.mozilla.org/listinfo/es-discuss



 ___
 es-discuss mailing list
 es-discuss@mozilla.org
 https://mail.mozilla.org/listinfo/es-discuss




 ___
 es-discuss mailing list
 es-discuss@mozilla.org
 https://mail.mozilla.org/listinfo/es-discuss




 --
 Cheers,
 --MarkM



 ___
 es-discuss mailing list
 es-discuss@mozilla.org
 https://mail.mozilla.org/listinfo/es-discuss


___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: How to tell function and generator function apart?

[Dean Landolt]

One use case is for coroutine runners which accept either generators or
generator functions:

https://github.com/deanlandolt/copromise/blob/master/copromise.js#L34-L36

Is there a better way to accomplish this?


On Tue, Mar 3, 2015 at 12:12 PM, Erik Arvidsson erik.arvids...@gmail.com
wrote:

 Why do you want to do this?

 It is an antipattern that we have covered before.

 On Tue, Mar 3, 2015 at 5:41 PM Guilherme Souza 19gu...@gmail.com wrote:

 Hi all,

 I was wondering how one could check if a given function is a generator
 function, is a cross-realm way:

 ```
 let f = function(){}
 let g = function*(){}

 typeof f === typeof g // 'function'

 f instanceof Function // true, but only in the same Realm
 g instanceof Function // true, but again only in the same Realm

 let GeneratorFunction = Object.getPrototypeOf(function*(){}).constructor
 f instanceof GeneratorFunction // false
 g instanceof GeneratorFunction // true, but only in the same Realm

 // This works, but relies on Function.prototype being a function itself.
 typeof Object.getPrototypeOf(f) // 'function'
 typeof Object.getPrototypeOf(g) // 'object'
 ```

 So what is the recommended way to do this type of check?
 Would something like `Array.isArray` for generator functions be helpful?

 Regards,
 Gui


 ___
 es-discuss mailing list
 es-discuss@mozilla.org
 https://mail.mozilla.org/listinfo/es-discuss


 ___
 es-discuss mailing list
 es-discuss@mozilla.org
 https://mail.mozilla.org/listinfo/es-discuss


___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: How to tell function and generator function apart?

[Dean Landolt]

On Tue, Mar 3, 2015 at 10:00 PM, Domenic Denicola d...@domenic.me wrote:

 That's not really the issue at hand, though. Your runner won't work with
 functions that manually return generator instances, due to its
 type-testing. Even if those functions return generator instances express a
 perfectly valid async program sequence.


I don't follow -- it definitely used to work (I use the past tense because
I went ahead and converted to do the async fn wrapper thing instead). The
type test was just to determine whether or not to flatten generator
functions into generator instances, which is what the coro trampoline
expects. Any generator instance can be run through that coro tramp -- even
ones not designed as coroutines (not recommended, of course -- though it'd
be fine so long as it terminates).

I just noticed the coro tramp in the async/await spec:
https://github.com/lukehoban/ecmascript-asyncawait#spawning. This is just
about identical to my own, though I can't quite figure out why it bothers
operating on generator functions rather than instances. It seems more
natural to instantiate the generators (and their argument bindings) from
within an async fn wrapper, e.g.
https://github.com/deanlandolt/copromise/blob/master/copromise.js#L23.

Removing the type test definitely cleaned up the API, and managed to shrink
an already tiny code base even more, so it was clearly a win. But I still
can't see how how type testing would have broken anything at all in the
previous design.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: How to tell function and generator function apart?

[Dean Landolt]

On Tue, Mar 3, 2015 at 5:26 PM, Domenic Denicola d...@domenic.me wrote:

 As discussed previously such overloading is pretty bad. If someone creates
 a generator-returning function manually, instead of using a generator
 function to do so, they will start getting unexpected results from your
 library. You might think this is rare but it's actually pretty
 reasonable---consider e.g. `yourLibrary(transform(function* () { ... }))`
 where `transform` is a higher-order function which manually creates a
 generator based on its argument.

 An analogy would be that your and Dean's functions are similar to
 something like

 ```js
 function getFullName(person) {
   if (person.constructor !== Person) {
 // Do something else, e.g. `return person.toString()`
   }

   return `${person.firstName} ${person.lastName}`;
 }
 ```

 That is, now you have prohibited people from using { firstName, lastName }
 object literals, Person subclass instances, Dog instances, etc. That's very
 unfortunate practice. The same goes for generators.


FWIW the coroutine runner in my example is strictly a runner, not a wrapper
returning something analogous to an async function. I definitely see the
benefit of such a wrapper (and have been meaning to get around to adding
one), but the example I'd linked to is more like running coroutine
program. I suspect there's still some benefit to this kind of style, if
just for simple debug cases, but with the presence of some kind of async
function wrapper, this program wrapper would really only need to support
generator functions, which means no need to bother w/ any
`isGeneratorFunction` nonsense.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: The result of Generator.prototype.return

[Dean Landolt]

On Wed, Feb 25, 2015 at 2:39 PM, Bergi a.d.be...@web.de wrote:

 Axel Rauschmayer schrieb:

  OK. I see the use case for `throw()` (e.g. to convert a promise rejection
 into an exception when using generators for async). The only use case for
 `return()` is closing an iterator, then(?)


 If you are using generators for async, then you'd call `return()` when
 your result promise is cancelled.


That seems a bit surprising to me -- I'd expect a cancelled promise to
result in some kind of exception being thrown into my coroutine-style
generator, not for execution to silently return out of the generator
entirely. IIUC calling `return` on a coroutine would be analogous to a
TCP-preserving control flow construct. While this could prove useful in the
future, it doesn't really line up with anything in the language as is, so
for POLA's sake, coro runners should probably stick to `next` and `throw`.

That said, perhaps it's worth contemplating other control flow constructs
to be invoked at the yield site, like break and continue (with label as the
argument)?
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: (x) = {foo: bar}

[Dean Landolt]

On Tue, Jan 6, 2015 at 3:57 PM, Marius Gundersen gunder...@gmail.com
wrote:

 I don't see how wellLabeledStatement will protect against object literals
 with shorthand properties, like (x, y, z) = {x, y, z}.


It would protect against them by disallowing them without the paren
wrapping. A fail-fast SyntaxError beats the hell out of trying to diagnose
an almost imperceptible runtime bug.


  The solution to the block vs object problem today is to wrap the object
 in parenthesis, but not the block. The only alternative that is easy for
 humans to understand and not ambiguous for machines is to wrap or prefix
 the block, but not the object, for example with do:

 x = do {
   let a = 5;
   return a*x;
 }

 AFAIK do expressions are not in ES6, but might be in ES7.


I don't follow -- this isn't a labeled statement. How would it be any
different from this?

x = {
  let a = 5;
  return a*x;
}


AFAIK nobody's proposed forbidding this form. How would do-expressions help
here? Sure, IIUC do-expressions would be a good solution for labeled
blocks, when they're available. But by es7 there's also plenty of time to
refactor the spec to allow some variant of /be's proposed
`WellLabeledStatement` grammar, which would allow well-formed labeled
statements w/o the do prefix.

Just to reiterate, I'm arguing that paren-wrapping should *still *be
required around object literal arrow bodies, now and forever. Anything else
would be impossibly confusing. But I can't see a reason to allow an
(accidentally) unwrapped object literal to parse. If it's not a
well-labeled statement, it's surely a mistake.

 Marius Gundersen
 On 6 Jan 2015 19:42, Brendan Eich bren...@mozilla.org wrote:

 Sorry, sent too soon.

 Dean Landolt wrote:

 If it's too late to properly vet a change which narrowly excludes from
 arrow bodies any `LabeledStatement` that isn't a `WellLabeledStatement`,
 would it be feasible to simply exclude any `LabeledStatement` for now? I
 doubt there's much code in the wild that would be affected by this change
 -- certainly not yet. That'd buy plenty of time to add back proper support
 for `WellLabeledStatement` arrow bodies in es7.


 The ES6 grammar has not been refactored per my old strawman. It has no
 WellLabeledStatement non-terminal.

 For ES6, we would need another production parameter to FunctionBody,
 FunctionStatementList, and StatementList (at least) by which to restrict a
 ConciseBody : { FunctionBody } such that the FunctionBody :
 FunctionStatementList (via FunctionStatementList : StatementList[opt],
 StatementList StatementListItem, etc.) doesn't start with a
 LabelledStatement.

 Cc'ing Allen and Waldemar for their thoughts.

 /be
 ___
 es-discuss mailing list
 es-discuss@mozilla.org
 https://mail.mozilla.org/listinfo/es-discuss


___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: (x) = {foo: bar}

[Dean Landolt]

On Mon, Jan 5, 2015 at 6:06 PM, Brendan Eich bren...@mozilla.org wrote:

 Jasper St. Pierre wrote:

 Unless

 x = {foo: bar}

 and

 x = {}

 both parse as object literals, I'm against your proposal. Either
 un-paren'd braces are consistently a block, or they're consistently an
 object literal. Python has had major pains with i before e except after c
 rules to make the language nicer to use, and it's easier to tell people
 always add the parens.


 Fair.

  A third option is to make x = {foo: bar} a syntax error to steer people
 away from an accidental footgun, while still making {} a block, and keeping
 the consistency of parens around object literals.


 Just about too late for ES6, though. Eep!


Is it though? ISTM there's consensus that this is a footgun -- isn't that a
kind of spec bug? If it's too late to properly vet a change which narrowly
excludes from arrow bodies any `LabeledStatement` that isn't a
`WellLabeledStatement`, would it be feasible to simply exclude any
`LabeledStatement` for now? I doubt there's much code in the wild that
would be affected by this change -- certainly not yet. That'd buy plenty of
time to add back proper support for `WellLabeledStatement` arrow bodies in
es7.

Implicitly returning object literals would still require paren wrapping, of
course -- and in light of the empty object / empty block ambiguity this
seems inevitable. And we'll get a fail-fast compile error for the common
case (non-empty objects) to would help educate and remind us all of the
distinction.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Promise-returning delay function

[Dean Landolt]

On Tue, Oct 28, 2014 at 10:41 AM, Andrea Giammarchi 
andrea.giammar...@gmail.com wrote:

 The moment you pass a promise you have no control on who's adding what as
 callback or errorback which means you have no control over a .reject() or
 over a .success()

 .cancel() would eventually keep both queues unresolved so that nothing
 should happen at all: no error handling, no error happened, and no actions
 needed ... it's simply canceled.

 This is the same reason .fetch() API needs also events to work properly
 (including `progress`) ... you cannot base as example typeahead on
 promises right now 'cause it's a mess to handle since response order is not
 guaranteed but you need to handle the .cancel() case without telling the
 user something else went wrong ... what you suggest, a `new Noop()` where
 `Noop.prototype = Object.create(Error.prototype)` ?

 And how do you instruct unknown surrounding code that an `if (err
 instanceof Noop)` should be the first line of every errback ?

 This is the reason few devs cannot adopt current standard Promises.

 `.cancel()` as well as `.abort()` is **very** important when many network
 operations are in place and/or you want to switch to a different state
 without waiting for the previous one to be fulfilled.

 `new Promise(function (resolve, reject, cancel) {});` is the dumbest idea
 I could have now beside `new Promise(function (resolve, reject)
 {}).on('cancel', cancelback).then(whatever)` one

 Anyway, this would deserve IMO a thread a part but I hope this topic will
 be discussed at some point.

 Best Regards



I agree w/ Scott re: regularity of flow control, and I'd be particularly
uneasy if a `cancel` method on a promise had any impact on upstream
handlers. But ISTM something like this could be made to work (even if it
looks a bit silly):

```js
var cancelled;
var never = new Promise(function () {});
Promise.delay(100/*ms*/).then(function(value) {
return cancelled ? never : value;
}, function (error) {
return cancelled ? never : throw error;
});
function cancel() { cancel = true };
```

This could be cleaned up into a cancellation helper to quash downstream
promises (this kind of utility would be a good use case for an `always`
method if one isn't yet spec'd).

Though I do wonder what happens to promises like these that get dropped on
the floor? Will downstream handlers be GC'd? Is this specified in any way?
I imagine dev tools want to warn about these kinds of promises — it may be
helpful to have a way to signal that a promise was intentionally quashed.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: My ECMAScript 7 wishlist

[Dean Landolt]

On Fri, Sep 26, 2014 at 10:29 AM, Brendan Eich bren...@mozilla.org wrote:

 Tab Atkins Jr. wrote:

 I don't understand how you inferred from Andrea's post that this
 wish-fulfillment __noSuchProperty__ magic property does not have to
 handle superclass delegation..


 I did not infer that from Andrea's post as his position -- rather the
 reverse, because he said I also think Proxy already gives us a way ...,
 to wit the code I showed earlier. Hence my confusion about what was being
 proposed that differed.

 At minimum it needs to handle
 delegating to the object's own prototype (it would be a pretty poor
 NSP if it couldn't handle methodMissing use-cases as well), and I
 don't think there's a reasonable case to stop at just one level up;
 doing so would make this very fragile to refactoring your hierarchy,
 as methods show up as missing or not depending on where they end up in
 the class hierarchy.


 Methinks you protest too much. Just put it below Object.prototype and get
 on with life. That was the idea, anyway.

 Yes, what you propose is more flexible. Also more costly. Good luck
 selling implementors! I hope Andreas will comment now.


Out of curiosity, wouldn't Object.observe require implementors to add
precisely this kind of hook into the vm anyway?
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Does async/await solve a real problem?

[Dean Landolt]

Yes, async/await solves one problem in particular that generators alone
cannot—the ability to `await` some asynchronous value from within a true
generator (one yielding actual values, not a coroutine yielding promises or
thunks into a trampoline). These coro trampolines are a clever hack, but
the async/await syntax allows these two completely distinct language
features to become truly orthogonal. This is important in its own right,
but also has immediately utility (e.g. more elegant lazy streams using
for-of iteration).

On Thu, Sep 11, 2014 at 5:45 AM, Jeswin Kumar jeswi...@agilehead.com
wrote:

 Looking at my project (in which asynchronous calls are entirely done
 via generators), I can't see how async/await would simplify code for
 end-users like me (application programmers).

 End users write the spawn()/Q.async()/co() wrapper *at most* one
 single time in an application:
 1. When using a framework like say koajs, you don't have to write it even
 once.
 2. While not using a framework, you'd have to use the wrapper one
 single time in say, the main.js file.

 To use the example at
 http://wiki.ecmascript.org/doku.php?id=strawman:async_functions

 async function chainAnimationsAsync(elem, animations) { CODE; }
 is just
 function chainAnimationsAsync*(elem, animations) { same CODE; }
 when flow control is done by a framework or at the entry point to your
 application. spawn() isn't needed.

 I can't see how this will reduce application's code even a little. So
 my question is, is async/await needed?


 One more question
 --
 1. yield is practically very difficult to use in a project because you
 don't get proper stack traces (at least with the current flow control
 libraries). You'd only see the last call which threw the error, and
 then functions from the flow control library immediately below that. I
 suppose the generators leading up to the erring generator are all
 suspended and wouldn't be on the stack frame chain.

 2. yield* generator delegation solves this problem, you get real stack
 traces. I was able to get full stack traces simply by replacing all
 yield X() with yield* X()

 example code as in: https://github.com/chopachom/syncio

 So if there are valid use-cases for adding async/await to JS,
 shouldn't it be based on how yield* works rather than yield?

 -- Jes

 The Fora Project is coming...
 https://github.com/jeswin/fora
 ___
 es-discuss mailing list
 es-discuss@mozilla.org
 https://mail.mozilla.org/listinfo/es-discuss

___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: restrictions on let declarations

[Dean Landolt]

On Thu, Jan 30, 2014 at 10:59 AM, John Barton johnjbar...@google.comwrote:




 On Thu, Jan 30, 2014 at 7:54 AM, Brendan Eich bren...@mozilla.com wrote:

 John Lenz wrote:

 Generally, I've always thought of:

 if (x) ... as equivalent to if (x) { ... }


 let and const (and class) are block-scoped. {...} in your if (x) {...}
 is a block. An unbraced consequent is not a block, and you can't have a
 conditional let binding.

 The restriction avoids nonsense such as

 let x = 0; { if (y) let x = 42; alert(x); }

 What pray tell is going on here, in your model?


 I'm with John: the alert should say 0 and I can't see why that is not
 obvious.



It's not obvious at all -- what happens when you drop the initial `let x =
0;` and you just have `{ if (y) let x = 42; alert(x); }` -- now what
happens? Is x declared or not?

To my mind `if (y) let x = 42;` reads like it's own 1-line noop block -- at
least, that's what I'd expect of the scope. So while it could be allowed in
that sense, it'd only serve as a footgun when y is true.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Operator overloading for non-value objects

[Dean Landolt]

Value Objects. See the recent thread re: value objects on es-discuss.
Slides from the presentation Brendan linked to (
http://www.slideshare.net/BrendanEich/js-resp) confirm that == will still
be overloadable and he says he'll be working on writing it all up this
month.


On Mon, Jan 13, 2014 at 5:45 AM, Anne van Kesteren ann...@annevk.nl wrote:

 In a discussion I had with Alex Russell as how to do comparison for
 URL objects it ended up with desiring

   url == url2

 to work. It escaped me at that point that I already discussed this
 briefly and Brendan explained why face-to-face. However, I forgot what
 he said :/

 The alternative, either something like

   url.equals(url2)

 or

   URL.equal(url, url2)

 or

   url.toString() == url2.toString()

 is somewhat Java-esque. Is that what we should do? And if so, opinions
 on which variant?


 --
 http://annevankesteren.nl/
 ___
 es-discuss mailing list
 es-discuss@mozilla.org
 https://mail.mozilla.org/listinfo/es-discuss

___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Operator overloading for non-value objects

[Dean Landolt]

On Mon, Jan 13, 2014 at 8:38 AM, Anne van Kesteren ann...@annevk.nl wrote:

 On Mon, Jan 13, 2014 at 1:13 PM, Dean Landolt d...@deanlandolt.com
 wrote:
  Value Objects. See the recent thread re: value objects on es-discuss.
 Slides
  from the presentation Brendan linked to
  (http://www.slideshare.net/BrendanEich/js-resp) confirm that == will
 still
  be overloadable and he says he'll be working on writing it all up this
  month.

 Value objects are immutable. URL objects do not have that quality
 which is why I titled this thread overloading for non-value objects...


Ah, I apologize -- I didn't bother reading the subject.

I'd only add that in spite of all the legacy, the mutation-heavy API of URL
objects seems pretty clunky, especially in the presence of value objects.
Ah well.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Why thenables?

[Dean Landolt]

True, though if you're using modules like that you won't need thenable
assimilation anyway -- you can count on your code having native promises.
If I understood Alex Russell correctly the core problem is cross-realm
promise polyfillability.

It seems to me we could solve this problem by just having promise libraries
monkey-patch Promise.prototype.then to assimilate. If you load a promise
lib into a realm it should patch then (and then perhaps agree on some way
to communicate to other promise libs not to bother patching the patch).

If there's no practical issues with collision (as advocates for
assimilation claim) this is an extremely low risk proposition. But again,
this would be completely opt-in so your code is only affected if you
*choose* to load a promise lib that does this.

This solves the core issue cleanly (as put forth by Alex, at least)
\without pissing in the namespace pool.


On Fri, Dec 20, 2013 at 11:13 AM, Kevin Smith zenpars...@gmail.com wrote:


 Presumably certain promise libraries would try reset the global Promise
 to AssimilatingPromise (or whatever) for full parity with polyfilled
 environments, which would be fine.


 If you're using modules, you wouldn't need to mess with the global object.
  You could just import AssimilatingPromise as Promise into the current
 module.  The local binding would override the global Promise variable.



___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Why thenables?

[Dean Landolt]

On Fri, Dec 20, 2013 at 12:38 PM, Kevin Smith zenpars...@gmail.com wrote:

 Okay, so how will end users or jQuery authors upgrade their promises to
 become ES6-compliant?


 I don't know enough about jQuery's internals to write convincing code, but
 the basic idea is that you feature detect for ES6 Promises.  If that test
 passes, then you implement jQuery.Deferred using a Promise subclass (which
 would do assimilation for backward compatibility reasons).  Otherwise you
 implement it the old-fashioned way.

 Application developers who are going to hook into the new DOM API's need
 to upgrade their jQuery.

 Of course, jQuery promises will still over-assimilate objects which have a
 `then` method but aren't thenable, but that's jQuery's backward
 compatibility problem, not the entire language's.

 Am I missing something?  I usually do...  : )



I'd only point out that jQuery's Deferred API varies pretty wildly from ES6
Promises, so this could end up pretty ugly.

The alternative is to just let jQuery be jQuery and upgrade (or bastardize,
depending on your perspective) ES6 Promises to assimilate. I don't know why
this didn't occur to me before -- it seems pretty much ideal.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: const VS features detection

[Dean Landolt]

On Fri, Dec 20, 2013 at 2:14 PM, Andrea Giammarchi 
andrea.giammar...@gmail.com wrote:

 This is not helping ... yeah, apples-to-orange, as you wish .. now to
 imagine you have a flexible understanding of the issue and the example I
 was proposing so that:

 if (stuff) {
   const WHATEVER = 1;
 } else {
   const WHATEVER = 2;
 }

 two blocks, one const assigned with possibly only one value

 Now tell me again how this works in C ...


As written above this couldn't possibly work in C -- const is block level,
right? Originally you wrote this with #ifdefs, which aren't blocks. This
isn't even close to apples-to-apples.

So are you suggesting that js grow a preprocessor? That block scoping
shouldn't *really* mean block scoping? Or that const shouldn't
*really*mean const? Best I can tell it could only be one of those
three -- and they
all sound bad to me.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: any toMethod() use case ?

[Dean Landolt]

On Tue, Dec 3, 2013 at 4:24 PM, Brian Di Palma off...@gmail.com wrote:

 This is sort of OT but not too much.

 I have a concern about how mixins will be implemented in ES.
 It concerns clashing property identifiers in mixins and the classes
 taking their behavior.

 By way of a simple example an Emitter could have a local property
 this.listeners for its own internal purposes.
 Likewise a class that mixes in Emitter could also have a local
 property this.listeners.

 I was wondering if the delayed Object.mixin implementation included
 some sort of sandboxing to deal with this case or if it was left to
 the discretion of the developer?

 I guess the obvious suggestion is to use Symbols in Emitters, does
 this mean sandboxing will not be a consideration for Object.mixin?

 You could imagine a new version of the Emitter introducing a new
 identifier that could clash and lead to tricky bugs especially if the
 mixin did not define the identifier until certain conditions were
 met..



It sounds like you're looking for Symbols.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Novel operator syntax

[Dean Landolt]

The PEP Tristan posted offers a pretty compelling case for distinguishing
elementwise operators from objectwise ones (although not for this dot
syntax per se, they went with a ~-prefix):
http://www.python.org/dev/peps/pep-0225/


On Tue, Oct 29, 2013 at 2:25 PM, Brendan Eich bren...@mozilla.com wrote:

 Tristan Zajonc wrote:

 Sorry, at most I'm only proposing every *existing* operator prefixed by
 ., not new operators.  So things like
 .+, ./, .*, .-., .%, .==, .!=, ., ., etc.  These would be called dot
 operators.  This is all that's required by the
 technical computing use case.


 Why is the dot needed, though?

 /be

 __**_
 es-discuss mailing list
 es-discuss@mozilla.org
 https://mail.mozilla.org/**listinfo/es-discusshttps://mail.mozilla.org/listinfo/es-discuss

___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Protocol library as alternative to refinements (Russell Leggett)

[Dean Landolt]

First off, this whole concept is brilliant. Thanks for sharing, Russell.
Just a few comments inline...


On Tue, Oct 22, 2013 at 2:13 AM, Russell Leggett
russell.legg...@gmail.comwrote:


  I can see most of your examples involve the interaction between the
 protocol method and a method supplied on the object itself... They
 definitely complicate things... I guess I would say that I would have this
 throw an error. ... Skipping foo on the object because its not a function
 seems too magical.

 Skipping `foo` on the object because it is not a function is too magical
 in my opinion too. Working out how instance methods work in this scenario
 seems like quite the task to me. The step of putting the protocol _between_
 the object and the prototype sounds pretty hard to get right in particular.
 I don't like thinking of reading from the prototype (as in the case of
 fetching a method) any differently from reading from the own object. After
 all sharing functionality is at the very core of prototypical inheritance.


 Yeah, I'm not exactly married to it, but I liked the idea of being able to
 override at the instance level, therefore giving own properties highest
 priority.



I think the idea of overriding at the instance level is appealing too, but
doesn't dispatching on a string key open the door to the kinds of naming
conflicts the concept so elegantly solves otherwise? One possible solution
might be for the protocol to also expose a symbol for each method that
could be used to override at the instance level.

I'd go further and suggest that it should walk the prototype too, since
adding a specific symbol from a protocol would be a very intentional
action. This might be a bit of a perf burden in naive implementations but
it seems like the right thing -- there's something a little off about
intervening between instance and prototype lookup. The whole point of the
prototype is that it's a default logic -- attempting to short circuit this
just smells wrong.


   Case 3:
  Ah, yes, I had thought about this a bit, but it had never made it into
 my gist at all. Let me revise my algorithm:
  4. true - use Bar.foo

 This makes some sense. About scope resolution more generally I just want
 to make a note that in C# extension methods, the extension method is always
 the _last_ candidate. It would check anywhere in the inheritance chain
 _before_ attempting to evaluate the extension method. For example:

```
 public class Bar
 {
 public int GetFive() { return 5;}
 }
 public class Foo : Bar{}

 public static class FooExt
 {
 static int GetFive(this Foo bar)
 {
 return ;
 }
 static string ToString(this Foo bar)
 {
 return Hi;
 }
 }
  static void Main(string[] args)
 {
 Console.WriteLine((new Foo()).GetFive()); // this prints 5
 Console.WriteLine(new Foo())); // Uses the implementation of
 Object.ToString .
 }
 ```

 This is a major difference between this proposal and C# extension
 methods. However, I'm not sure it's bad. Would you mind making an argumnt
 for prioritizing the protocol method over an object method?


 Well I would start by pointing out that the two really are different
 mechanisms with different strengths and weaknesses. Protocols are more than
 a means of extension - they are also polymorphic and can really take
 advantage of the equivalent of interfaces across data types in addition to
 their extension. In a way, they are more similar to Haskell typeclasses
 than extension methods. There is also the obvious difference that protocols
 can be efficiently implemented in a dynamic language where extension
 methods cannot :)

 So anyway, the reason why prioritizing protocols is because there is
 potential value in the protocol itself. The protocol *is* an interface - a
 contract which can be polymorphic over different types. The same way that
 two protocols can have methods with the same name but different semantics,
 it would make sense that a protocol could be defined, and need to be
 applied to a type that already has the method. There is value for the
 protocol version to override the type's built in version. Because there is
 no ambiguity in the intent of using the protocol instead of the prototype,
 I think protocol should win. C# uses uniform syntax so the intent cannot be
 known if the extension method was intended vs the type's method. Even
 interfaces in the Java/C# worlds can't handle that type of clashing. If two
 interfaces have methods with the same name and signature, you can only have
 a single implementation. In those languages it is rarely a problem because
 of the ability for overloading, but with JavaScript its just one name, one
 method.

 I'm not opposed to simplifying the algorithm, and perhaps protocol methods
 should always take a backseat similar to C#, but that just doesn't seem
 right to me. If I create a protocol 

Re: Protocol library as alternative to refinements (Russell Leggett)

[Dean Landolt]

On Tue, Oct 22, 2013 at 11:26 AM, Benjamin (Inglor) Gruenbaum 
ing...@gmail.com wrote:



 Russell, thanks for the reply, it clarified a lot. I just wanted to
 mention that I did not bring up C# extension methods to suggest this
 behavior for protocols but just to illustrate how a different system for
 addressing a similar problem (in a different environment) does it. I do not
 think Protocols should behave this way :)

 On Tue, Oct 22, 2013 at 9:13 AM, Russell Leggett 
 russell.legg...@gmail.com wrote:
   I don't like thinking of reading from the prototype (as in the case
 of fetching a method) any differently from reading from the own object.
 After all sharing functionality is at the very core of prototypical
 inheritance.
 Yeah, I'm not exactly married to it, but I liked the idea of being able
 to override at the instance level, therefore giving own properties highest
 priority.

 I think there is a very specific problem Protocols attempt to solve. I
 think that problem is sharing and adding functionality to a type in a
 scoped manner. Our other mechanisms for sharing functionality, prototypical
 inheritance and mixins do not scope well. What protocols give us is the
 ability to share functionality without having to modify the object. I think
 the syntax is also really nice and clever.  (so far I'm not saying anything
 new)

 The way method resolution on the object itself works right now in
 protocols sounds pretty complicated though. What if we make it a part of
 the protocol instead? What if protocols had a way to define preferring the
 object implementation? Don't we already have that in Protocols?

 MyProtocol.extend(Array, {map:Array.prototype.map}); // sorry if that's
 incorrect syntax

 Doesn't this let me define that when encountering an array I prefer its
 own implementation over the protocol's? What does it really cost us to drop
 checking the object and its prototype rather than using the protocol method
 always?

 If anything, I'd use the object own properties and prototype chain as a
 last fallback after protocol options have been exhausted. I don't really
 see an obvious use case where I want to polymorphically prefer the object
 implementations over the protocols and if I do, I can just use
 Protocol.extend to specify that in that case.

 The only other thing that bothers me in the spec is that you specify by
 classes which sounds a bit problematic to me (I don't see an obvious
 behavioral way though (how do I say Array like?), and having a default
 implementation kind of addresses that).

 On Tue, Oct 22, 2013 at 5:35 PM, Dean Landolt d...@deanlandolt.com
  wrote:

  I think the idea of overriding at the instance level is appealing too,
 but doesn't dispatching on a string key open the door to the kinds of
 naming conflicts the concept so elegantly solves otherwise?
  I agree that arr.map is questionable for protocol walking, but it's just
 as questionable on the instance because of possible name conflicts!

 What naming conflicts do you see here?


Say you have an object for which you want to implement the Cowboy and
Canvas protocols (to borrow /be's favorite example). Both implement a
draw method, but when you try to import from both protocols you'll
naturally have to rename one or both. Now say you want to override Cowboy's
`draw` method on an instance? You'll end up clobbering the Canvas
protocol's draw method with the obviously wrong function. Not cool. This
can be easily corrected with Symbols.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Protocol library as alternative to refinements (Russell Leggett)

[Dean Landolt]

On Tue, Oct 22, 2013 at 12:19 PM, Benjamin (Inglor) Gruenbaum 
ing...@gmail.com wrote:

 Dean Landolt d...@deanlandolt.com wrote:
  Say you have an object for which you want to implement the Cowboy and
 Canvas protocols (to borrow /be's favorite example). Both implement a
 draw method, but when you try to import from both protocols you'll
 naturally have to rename one or both. Now say you want to override Cowboy's
 `draw` method on an instance? You'll end up clobbering the Canvas
 protocol's draw method with the obviously wrong function. Not cool. This
 can be easily corrected with Symbols.

 I'm not sure I understand the example. What does a Cowboy's draw method
 do? Is it a specification of the Canvas protocol draw ?


They are two entirely different protocols.


 (In that case `.extend`ing the protocol seems to solve it). If you have a
 more concrete use case that would really help.


Picture any two protocols that share a method name. Think of another
protocol with a map method that means something entirely different from
Collections.methods.map. The specifics aren't important -- just the idea
that these are two independent protocols. You don't want to override a
method of one and accidentally override the other.


 I don't see how this is any different from other variables and general
 naming conflict issues when destructuring.


The difference is that protocols purport to solve this confusion problem --
it's one of their primary motivations.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Protocol library as alternative to refinements (Russell Leggett)

[Dean Landolt]

On Tue, Oct 22, 2013 at 12:44 PM, Russell Leggett russell.legg...@gmail.com
 wrote:


 Say you have an object for which you want to implement the Cowboy and
 Canvas protocols (to borrow /be's favorite example). Both implement a
 draw method, but when you try to import from both protocols you'll
 naturally have to rename one or both. Now say you want to override Cowboy's
 `draw` method on an instance? You'll end up clobbering the Canvas
 protocol's draw method with the obviously wrong function. Not cool. This
 can be easily corrected with Symbols.



 Yes, I'm liking this idea. Protocol always first - override through a
 symbol. Honestly, the more I think about it, the more I think overriding
 won't happen much and therefore isn't a huge problem, making it more
 specific through a symbol is not a bad idea.

 Last question - what about the priority of the defaults? Are they still
 prioritized over prototype? I was worried at first about unintentional
 clobbering the other way, but then realized that its easy to check for the
 method in the default if you want to prioritize the prototype over the
 default.

 Cowboy.defaults({
 draw(){
 if(typeof this.draw === function){
 this.draw();
 }else{
 //something here
 }
 }
 });



This is an interesting point -- the implementation could choose whether or
not to dispatch to an instance, and how. At this point I wouldn't call them
defaults since they'd always be run, and would be responsible for their
own dispatching. I still think dispatching on strings would defeat one of
the biggest advantages of protocols, but this approach is flexible enough
to allow that. Also, it doesn't try to intercede between own and prototype
lookup, which is much nicer.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Protocol library as alternative to refinements (Russell Leggett)

[Dean Landolt]

On Tue, Oct 22, 2013 at 4:07 PM, Russell Leggett
russell.legg...@gmail.comwrote:

 On Tue, Oct 22, 2013 at 2:34 PM, Benjamin (Inglor) Gruenbaum 
 ing...@gmail.com wrote:

 On Tue, Oct 22, 2013 at 8:10 PM, Russell Leggett 
 russell.legg...@gmail.com wrote:

  Revised algorithm:
  1. If receiver has protocol method symbol as a property, use that as
 override.
  2. Try to use protocol methods - start by checking receiver type
 mapping, then check up type hierarchy for any matches, and finally if no
 matches, use the default if defined.
  3. Finally, if no matches and no default, check prototype for method of
 same name.
  Does that sound better?

 Much :)


 Actually, let me revise 3:
 3. Finally, if no matches and no default, attempt to call a method of the
 same name (not affected by variable name or aliasing) on the receiver.

 Something like this:

 const P = new Protocol(foo);

 // naive, non-native implementation of P.methods.foo would be
 something like
 function foo(...args){
 if(P.symbols.foo in this){
 //P.symbols holds a symbol for each method
 return this[P.symbol.foo](...args);

 }else if(P.contains(Object.getPrototypeOf(this))){
 //contains and lookup might be backed by a weakmap or
 something,
 //but it would also need to go up the type chain
 let myFoo = P.lookup(Object.getPrototypeOf(this)).foo;
 return this::myFoo(...args);

 }else if(P.getDefaults().hasOwnProperty(foo)){
 let defaultFoo = P.getDefaults().foo;
 return this::defaultFoo(...args);

 }else{
 this.foo(...args);
 }
 }

 If this seems acceptable, I'll update the gist.


This seems sensible, though it's a bit more flexibility than I'd prefer.
What's not completely clear to me is whether this dispatching is defined by
the protocol method implementation or whether it's something that's
standardized? If the latter, I'd be concerned by all this flexibility. If
it's the former (and you can just grab a dispatch implementation from some
module) I guess it doesn't matter.

So *if *the implementation controls the dispatching, the point I was trying
to make about the default method not really being default is just that it
could just as well be inlined. Sure, it'd be nicer if it was defined
separately so they can be extracted and used independently, but assuming
custom dispatch then defaults are really up to your dispatch algorithm,
right? Do I have this about right?
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Readdition of __proto__

[Dean Landolt]

On Mon, Oct 14, 2013 at 8:32 PM, Allen Wirfs-Brock al...@wirfs-brock.comwrote:


 On Oct 14, 2013, at 4:21 PM, Andrea Giammarchi wrote:

  my last memories on the topic are these:
 
  ```javascript
 
  var obj = JSON.parse('{__proto__:[]}');
  obj instanceof Array; // false
  obj.__proto__ instanceof Array; // true
  // since the proto is a property, not a magic thing
  obj.__proto__ = 123; // da hell will happen, only Allen knows ^_^
 
  ```
 
  And since latter should simply set the property named `__proto__` as
 value `123` I got confused with this dual way to deal with an object when
 it comes from JSON world (then has a property defined as value, not the
 inherited set/get from Object.prototype)
 
  As summary, `JSON.parse` over `__proto__` is similar to:
  ```javascript
 
  var o = {};
  Object.defineProperty(o, '__proto__', {
value: 123,
enumerable: true,
writable: true,
configurable: true
  });
 
  ```
 
  Which means in such case the property `__proto__` will fail with such
 object while `Object.setPrototypeOf` won't which is the reason I keep
 suggesting the latest to make the intent explicit.
 
  Not arguing or anything, just speaking out loudly my confusion with that
 property as string part.
 

 I think you are over thinking this:

 Assuming that Annex B.2.2.1 and B.3.1 are implemented: here are the cases
 of interest:

 let o1 = {__proto__: p};  // o1 inherits from p
 let o2 = {__proto__: p};   // o2 inherits from p
 let o3 = {[__proto__]: p};// o3 inherits from Object.prototype, has own
 data property __proto__ whose value is p.
 let o4 = JSON.parse('{__proto__: value}');
   //o4 inherits from Object.prototype, has own data property
 __proto__ whose value is value

 //assuming that Object.prototype.__proto__ has not been tamper with:
 let o5 = new Object;
 o5.__proto__ = p ; //o5 inherits from p

 let o6 =new Object;
 o6[__proto__] = p; //o6 inherits from p


There seems to be an interesting case missing:

let attr = __proto__;
let o7 = new Object;
o7[attr] = p; // is this like o3?
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Readdition of __proto__

[Dean Landolt]

On Tue, Oct 15, 2013 at 5:50 PM, Brendan Eich bren...@mozilla.com wrote:

 Benjamin (Inglor) Gruenbaum wrote:

 Not resolving this like o3 (or o6 really) sounds very strange. I think:

 let attr = __proto__;
 let o7 = new Object;
 o7[attr] = p; // o7 inherits from p

 Is the correct behavior here (why would it not invoke the setter?)


 Allen confirmed, but just to be clear, any world where o[foo] and do {
 let key = foo; o[key]; } (do-expression syntax from harmony-era strawman)
 differ is crazytown, and we do not go there.


True, but the __proto__ train left the station bound for crazytown long
ago...

So just to be clear, the only way to add a __proto__ property to an
existing object is with Object.defineProperty?
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Comments on Sept Meeting Notes

[Dean Landolt]

On Wed, Sep 25, 2013 at 12:04 AM, Kevin Smith zenpars...@gmail.com wrote:


 This seems like a non-sequitur.  Symbols aren't meant to help with the
 object as map use-case, and even if you tried to, they work terribly
 for it.  They're meant for the add an actual property/method without
 collision use-case.  Again, Maps seem like a non-sequitur here -
 using a Map doesn't aid with avoiding collisions.


 Before Maps, I might use a regular object to store arbitrary
 string-to-value mappings.  Say I'm counting the occurrences of terms
 appearing on es-discuss.  The key std:iterator might actually occur.  In
 that case we would have a collision with my proposed meta-level property
 name.  But going forward, no one's going to use a regular object for
 arbitrary string keys - it's simply too error-prone.  They'll use a Map
 instead.  Which means that we don't have to worry about arbitrary string
 keys colliding with meta-level property names.

 Now, one might argue that using the string std:iterator (or equivalent)
 would present a backward compatibility hazard for legacy code using objects
 as maps.  I'll have to think about that one...

 The argument is that, once you take out arbitrary string keys (as occur
 when using an object as map), a namespaced string provides sufficient
 collision resistance to make symbols unnecessary.


 How is this in any way better than:

 class C {
   std_iterator() { ... }
 }


 The set of non-identifiers is less commonly used for member names by far,
 so it has that advantage.  But I'm not really saying that std:iterator is
 better than std_iterator.  I'm saying that both are a simpler solution
 than symbols.



You call namespaced strings more convenient than symbols, serves the
purpose equally well. These two things are obviously not equivalent --
namespaced strings are obviously weaker. We could use them today, yet
hardly anyone does this, because it's inconvenient in it's own ways. Yet
name collisions happen all the time in the wild, even with ad hoc
namespaces, and this is the problem symbols completely solve. Ad hoc
namespaces *can't* solve the collision problem and obviously *don't* solve
convenience problem -- if they did, we'd already be using them.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Letting RegExp method return something iterable?

[Dean Landolt]

On Thu, Aug 29, 2013 at 4:13 AM, Brendan Eich bren...@mozilla.com wrote:

 Axel Rauschmayer wrote:

 * /g flag must be set
 * lastIndex must be 0
 * can’t inline the regex, because it is needed as a pseudo-iterator (more
 of an anti-pattern, anyway, but still)
 * side effects via lastIndex may be a problem


 Anything we do of the execAll/execIter kind had better be immune to the
 awful Perl4-infused mutable lastIndex state but only if global kind.
 Compositionality required.

 The design decision to face is what to do when a global regexp is used.
 Throw, or ignore its lastIndex?



I'd hate to see it throw. Ignoring lastIndex seems friendlier, especially
if it were called `execAll`. It probably shouldn't be called `execIter`
considering `exec` is already an iterator (even if a bit crazy).

I'd love to be able to `send` a specific index to the generator, which
would be completely equivalent to `RegExp.prototype.exec` without the
lastIndex smell.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Why not private symbols?

[Dean Landolt]

On Wed, Jul 31, 2013 at 8:50 AM, Kevin Smith zenpars...@gmail.com wrote:


 Aside from this confinement issue, all other the advantages that unique
 symbols have over unique-ish strings seem minor to me. The biggest is
 default non-enumerability, when we're getting away (admittedly slowly) from
 enumerability being significant anyway. IMO, if the only advantages of
 unique symbols over unique-ish strings are these minor ones, then they
 don't pull their weight.


 The fact that, in the context of *unique* symbols, the unforgability
 property of the symbol is pointless indicates to me that we might have a
 mixing of orthogonal concerns.



Unforgability is pointless, sure, but not so fast: as Brendan suggested at
a few days back re: MAC addresses and such, you can't ignore the difference
between collision-*proof* and collision-*resistant.* The difference is
identity -- object (and symbol) identity is intrinsic, string identity is
extrinsic. If we're talking about keys we're talking about identity -- this
is not at all orthagonal.

I'm not arguing that this is enough of a justification for symbols
(especially in lieu of privates), but we can't hand-wave this distinction
away -- it's essential.


That leaves default non-enumerability.  Consider the fact that object
 literal methods are enumerable.  Why should choosing a unique name as
 opposed to an identifier for a method have any bearing on enumerability?



Because GUID-unique-strings are ugly? /troll

I know there's still a ton of unguarded for/in over object keys. I'll admit
to using it from time to time -- it's the easiest way to pick up enumerable
prototype keys, and plenty safe -- so long as you zealously guard
Object.prototype.

I still see the occasional for/in over arrays that would fail hard, but
that's harder to defend :)
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Agreeing on user-defined unique symbols?

[Dean Landolt]

We have exactly the same problem with inter-realm instanceof.

The module system is the obvious solution for system-defined unique
symbols. I've been assuming it could be hacked (one way or another) into
giving us a registry where we could map string keys to symbols across
realms. I get that this hack does nothing but bifurcates the namespace into
*plain strings* and *symbol strings*. But for some cases this is a fine
solution -- seems to work fine for ruby and smalltalk.

Maybe this would even merit syntax or some other language level treatment.
If user-defined symbols come to pass (GUID-backed or otherwise) I'm sure *at
least one* version of this kind of string-backed registry hack will pop up.
Is it better to get ahead of it and limit it to only one by prescribing a
solution (in spec. or elsewhere)?


On Wed, Jul 31, 2013 at 11:03 AM, Mark Miller erig...@gmail.com wrote:

 This point is important enough that I'm resending as the start of a new
 thread.


 On Wed, Jul 31, 2013 at 7:50 AM, Mark S. Miller erig...@google.comwrote:


 In thinking about this, I become ever more puzzled about the versioning
 and inter-realm problems for user-defined unique symbols -- I think it may
 be a train wreck. Scenario: Library W version 1.1 defines and uses a unique
 symbol @foo which is loaded into realm A. Library W version 1.2 purposely
 intends to continue to define and use the same unique symbol @foo, so
 that W1.2 code can successfully handle instances of W1.1 code. Library W1.2
 is loaded into realm B. The two realms come into contact, and objects from
 the two W's come into contact. *How did they both coordinate to define
 and use the same @foo symbol?*




 --
   Cheers,
   --MarkM

___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Why not private symbols?

[Dean Landolt]

On Wed, Jul 31, 2013 at 10:50 AM, Mark S. Miller erig...@google.com wrote:




 On Wed, Jul 31, 2013 at 6:24 AM, Dean Landolt d...@deanlandolt.comwrote:




 On Wed, Jul 31, 2013 at 8:50 AM, Kevin Smith zenpars...@gmail.comwrote:


  Aside from this confinement issue, all other the advantages that
 unique symbols have over unique-ish strings seem minor to me. The biggest
 is default non-enumerability, when we're getting away (admittedly slowly)
 from enumerability being significant anyway. IMO, if the only advantages of
 unique symbols over unique-ish strings are these minor ones, then they
 don't pull their weight.


 The fact that, in the context of *unique* symbols, the unforgability
 property of the symbol is pointless indicates to me that we might have a
 mixing of orthogonal concerns.



 Unforgability is pointless, sure, but not so fast: as Brendan suggested
 at a few days back re: MAC addresses


 Don't ever use MAC addresses, dates, times, positions, etc, as sources of
 uniqueness. What a collision resistant string? Use 128 bits of entropy.
 You'll get an accidental collision of these with the same rarity as you
 will for two unique symbols because of an undetected memory error.




  and such, you can't ignore the difference between collision-*proof* and
 collision-*resistant.* The difference is identity -- object (and symbol)
 identity is intrinsic, string identity is extrinsic. If we're talking about
 keys we're talking about identity -- this is not at all orthagonal.



 

 In thinking about this, I become ever more puzzled about the versioning
 and inter-realm problems for user-defined unique symbols -- I think it may
 be a train wreck. Scenario: Library W version 1.1 defines and uses a unique
 symbol @foo which is loaded into realm A. Library W version 1.2 purposely
 intends to continue to define and use the same unique symbol @foo, so
 that W1.2 code can successfully handle instances of W1.1 code. Library W1.2
 is loaded into realm B. The two realms come into contact, and objects from
 the two W's come into contact. *How did they both coordinate to define
 and use the same @foo symbol?*

 



I responded in separate thread, but I'd add that this problem exists
regardless of the mechanism chosen for doing unique. It's not a problem of
symbols but of intrinsic object identity. This is why I believe modeling
symbols as stateless frozen objects is most sensible and correct thing.



 I'm not arguing that this is enough of a justification for symbols
 (especially in lieu of privates), but we can't hand-wave this distinction
 away -- it's essential.


  That leaves default non-enumerability.  Consider the fact that object
 literal methods are enumerable.  Why should choosing a unique name as
 opposed to an identifier for a method have any bearing on enumerability?



 Because GUID-unique-strings are ugly? /troll


 That's why you refer to them symbolically. Just like we write Math.PI in
 good code, rather than 3.14159...



Agreed -- I was mostly joking. But there's a reason the proposal called for
a string prefix -- they will be reflected in the raw. Unlike Math.PI, this
raw value is meaningless.




 I know there's still a ton of unguarded for/in over object keys. I'll
 admit to using it from time to time -- it's the easiest way to pick up
 enumerable prototype keys, and plenty safe -- so long as you zealously
 guard Object.prototype.

 I still see the occasional for/in over arrays that would fail hard, but
 that's harder to defend :)


 This is the enumerability issue which I already acknowledged, right? Is
 there anything more to this?



I was responding directly to Kevin's comment:

That leaves default non-enumerability.  Consider the fact that object
literal methods are enumerable.  Why should choosing a unique name as
opposed to an identifier for a method have any bearing on enumerability?


I was pointing out the very real hazard that exists in code which wouldn't
be considered objectively bad. To be explicit, I'm claiming that for/in
over object keys can be the Right Thing in cases where you want all
enumerable keys up through the prototype. If unique symbols aren't
enumerable *and* the platform demands any of them on Object.prototype this
will introduce subtle run-time breakages at least as badly as null
typeof. Even if es6 avoids them on Object.prototype who's to say they won't
be needed in later versions? This will bite eventually.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Agreeing on user-defined unique symbols?

[Dean Landolt]

On Wed, Jul 31, 2013 at 12:27 PM, Mark Miller erig...@gmail.com wrote:

 On Wed, Jul 31, 2013 at 8:36 AM, Erik Arvidsson 
 erik.arvids...@gmail.comwrote:

 One way could be to have a shared module with the symbol that both
 w1.1 and w1.2 uses.

 // w-symbols.js
 export let foo = Symbol();

 // w-1.1.js
 import {foo} from 'w-symbols';
 ...

 // w-1.2.js
 import {foo} from 'w-symbols';
 ...


 Where does the w-symbols module come from? Remember that initially w1.1 is
 loaded into realm A without knowledge of realm B and vice versa. Let's also
 say, to emphasize the point, that they're also under disjoint module
 loaders, so at the time they're initialized they can't use a common module
 loader as a rendezvous point for new definitions.




 Other options include storing the symbol in some kind of global
 registry (which the module registry is doing above).


 I know of only two such notions of a global registry:
 * One that would also serve as a global communications channel, which is
 therefore disqualified
 * The equivalent of an interning table, as in the symbol tables of
 smalltalk that Dean mentions.


 An interning table from JS strings to unique symbols would have the
 property that

 intern(str1) === intern(str2) iff str1 === str2

 The cool thing about an such interning table is that it is global mutable
 state that does not provide a global communications channel.

 To avoid accidental collision on the interned symbols, you must avoid
 accidental collision on the strings used as keys in this registration
 table. This demands exactly as much collision resistant of string choices
 as using the strings directly. And therefore also demands strings which are
 just as ugly.



Not exactly -- it's a fresh namespace, so no legacy collisions are
possible. Of it immediately becomes a landgrab, similar to npm package
names -- or even better, identical to global object today. This is a social
problem, and the incentives to play fair have proven effective.

This registry would have the secondary effect of functioning as a universal
*concept* registry, e.g. the IANA link relation types [1].

[1] http://www.iana.org/assignments/link-relations/link-relations.xhtml
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Agreeing on user-defined unique symbols?

[Dean Landolt]

On Wed, Jul 31, 2013 at 1:50 PM, Kevin Smith zenpars...@gmail.com wrote:


 unique string (uuid or otherwise) suffer same problem if generated in 2
 different realm unaware of each other.


 I meant hard-coding such a well-known unique string into both versions of
 the library.  That solves the problem.



And the next step? Someone will hash a well-known string to get their
well-known unique symbol and write a blog post calling it a best practice
:)
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Agreeing on user-defined unique symbols?

[Dean Landolt]

Why a third namespace when there's the built-in modules that functions
nicely as our registry?


On Wed, Jul 31, 2013 at 1:57 PM, Tab Atkins Jr. jackalm...@gmail.comwrote:

 On Wed, Jul 31, 2013 at 10:56 AM, Brendan Eich bren...@mozilla.com
 wrote:
  Domenic Denicola wrote:
  org.ecmascript.es6.builtins.iterator?
 
  You forgot the smiley, or: nooo!!

 Which is why I (not in jest) suggested the third property namespace,
 for language-defined symbols. ^_^

 ~TJ
 ___
 es-discuss mailing list
 es-discuss@mozilla.org
 https://mail.mozilla.org/listinfo/es-discuss

___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Unique Public Symbols as Strings

[Dean Landolt]

On Mon, Jul 29, 2013 at 4:29 PM, Brendan Eich bren...@mozilla.com wrote:

 Brandon Benvie wrote:

 On 7/29/2013 1:09 PM, Brendan Eich wrote:

 Brandon Benvie wrote:

 On 7/29/2013 11:33 AM, Kevin Smith wrote:

 The value of uniqueness lies in the fact that you can design protocols
 without having to globally coordinate on property or method names.  (E.g.
 iterator)


 I think {keys, maps, values} (and the pivot to using Symbols and
 functions for them)


 BTW that was just one thought (from me), and TC39 went another way to
 avoid the 'values'/with incompatibility found via Ext.js. (See the meeting
 notes for the first day, about the @unscopeable list.)

   Ah right, forgot about that. Another example (in the wild) is
 SpiderMonkey's use of iterator for the iteration protocol.


 In ES4 days it was __iterator__, after dunder-iter in Python.

 More recently, Jason implemented 'iterator' for two reasons, I think: 1,
 lack of symbol spec of implementation as prerequisite; 2, belief that a
 public name was better. Jason argued that case here, but I don't think he
 prevailed (Dean Landolt disagreed).



FWIW Jason convinced me in the end -- I was subtly misinterpreting the
spec. I still believe symbols (or something like them) are really
important, just not necessarily for iterators.

I'd also like to echo the sentiment in favor of private symbols. Unique
symbols really don't offer much over GUIDs, and don't make a whole lot of
sense in a world without private symbols. And in a world with private
symbols unique symbols aren't strictly necessary.

I don't fully grok the relationships strawman yet but it looks really
promising. I wonder what a *maximally minimal* version of it might look
like -- if it could be stripped down enough to just accommodate the needs
of the es6 spec. while remaining palatable and leaving the door to private
symbols open? Anything to avoid GUIDs. I'd bet most everyone would concede
they're are a smell, an es-regret waiting to happen :)

[snipped]
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: How primitive are Symbols? Bignums? etc

[Dean Landolt]

On Fri, Jul 19, 2013 at 12:31 PM, Andreas Rossberg rossb...@google.comwrote:

 On 19 July 2013 18:17, Allen Wirfs-Brock al...@wirfs-brock.com wrote:
  You have to be able to support Proxy exotic objects so, I don't see why
 you won't use that exact mechanism for Symbol objects.

 Because they are different. There is no useful unified mechanism for
 exotic objects, at least no efficient one. Every new form of exotic
 object will be a new special case. As I said, the nice spec-level MOP
 abstraction is largely irrelevant at the implementation level.

 I'm speaking from V8 experience here, but I would be surprised if the
 situation is much different in other modern VMs.

  In other words, use a self-hosted Proxy-based implementation for Symbol
 objects. The  MOP operations on Symbol exotic objects in all cases either
 throw an exception or return some predetermined result such as undefined or
 false.

 You can't use proxies for symbols -- they are special in parts of the
 semantics (and that includes their wrappers, if we want them to be
 special, too).



I'm curious how symbols differ semantically from null-prototype, empty,
frozen objects? I can't think of any substantive differences other the
power to act as object keys (and some seemingly insignificant details like
toString behavior). If that's truly the case, wouldn't it be a lot easier
to just allow any null-prototype, empty, frozen object to have the
object-key capability?

For consistency Object.prototype.toString could even be specified to return
something along the lines of [object Symbol] for values which fulfill this
criteria (a breaking change, but only very slightly -- I can't imagine this
affecting code in the wild).



 And I doubt that you will be able to use them for other
 exotic objects we might come up with (e.g. value objects would have
 special equality behaviour that proxies can't simulate).

 Even if you could, I highly doubt that proxy performance will ever be
 up for the task, at least not for an implementation cost that isn't
 much higher than the special casing.

 /Andreas
 ___
 es-discuss mailing list
 es-discuss@mozilla.org
 https://mail.mozilla.org/listinfo/es-discuss

___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: How primitive are Symbols? Bignums? etc

[Dean Landolt]

On Fri, Jul 19, 2013 at 2:48 PM, Andreas Rossberg rossb...@google.comwrote:

 On 19 July 2013 19:41, Dean Landolt d...@deanlandolt.com wrote:
  I'm curious how symbols differ semantically from null-prototype, empty,
  frozen objects?

 They differ in that the extra cruft that's needed to represent random
 objects is a complete waste of space on them. Also, there is a
 performance benefit if they can share a common representation with
 strings, so that you don't need a case distinction in every place
 dealing with property names (e.g. wrt to hashing).

 In any case, I don't want to focus exclusively on the implementation.
 I also think that there are obvious semantic and usability reasons for
 making them as similar to existing types as possible (esp strings,
 which they are closely related to).



I completely agree that it makes sense to keep them as similar as possible
to existing types. in fact, I'm just extending your argument a bit, but
picking one nit: symbols are more like objects than strings.

Since they're only useful as keys what matters for our purposes is their
unique, unforgeable identity, which they share in common with any other
object. The only thing they have in common specifically with strings (and
not other primitives) is the special capability to act as an object key.
But again, what matters here is *how* -- their intensional identity is
crucially different than the extensional identity of strings.

There's no reason I know of why this capability of being able to key an
object property couldn't be extended from strings to objects -- provided,
of course, that the objects are completely stateless and frozen. Isn't this
the very definition of a Symbol? A symbol is just a stateless frozen object
-- do we really care what it toString's to? Once an object is stateless and
frozen it can't be anything but stateless and frozen, thus any stateless
frozen object could just as well be a symbol. Sure, the language can spec a
Symbol constructor to make it easier to mint stateless frozen objects, but
is there any difference?

So if your ends is to keep symbols as close as possible to existing types I
think suspect this approach does you one better -- it makes Symbols a
perfect subtype of one of the built-ins -- just not the one you were
thinking :)


 I can't think of any substantive differences other the power
  to act as object keys (and some seemingly insignificant details like
  toString behavior). If that's truly the case, wouldn't it be a lot
 easier to
  just allow any null-prototype, empty, frozen object to have the
 object-key
  capability?

 Unfortunately, making other objects into keys would break existing
 code that assumes a ToString conversion for those.



Perhaps. I know it'd be breaking -- perhaps I'm not being imaginative
enough about the kind of code it could break. I doubt I've written code
that would break on this, but I've *definitely* written code that will
break if the range from typeof is expended.

Regardless, I doubt it'd even be useful to hack the spec for a special
toString. Is there any reason a symbol's toString couldn't return [object
Object]? if this is the only drawback to normalizing symbols in the way I
suggest, it seems like a small price when all the other quibbles being
debated melt away.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Frozen Date objects?

[Dean Landolt]

On Thu, Jul 18, 2013 at 12:44 PM, Norbert Lindenberg 
ecmascr...@lindenbergsoftware.com wrote:


 On Jul 17, 2013, at 20:35 , Brendan Eich bren...@mozilla.com wrote:

  Norbert Lindenberg wrote:
  On Jul 17, 2013, at 17:27 , Mark S. Millererig...@google.com  wrote:
 
  This is unfortunate. It does answer Anne's question though, in an
 unpleasant way: Date instances cannot be immutable; they can be at best
 readonly. Despite lack of any authorization to track the user's position,
 Date instances make visible their machine's mutable current position, as
 coarsened to the timezone.
 
  Just as a Date instance snapshots the time when it was created, I
 think it should also snapshot the timezone where it was created. Then it
 would be possible to contemplate immutable Date instances. Only the Date
 constructor should give the ability to sense changes to time and place, not
 the instances it makes. Virtualizing the Date constructor (replacing it
 with a faux Date constructor) should be adequate to create illusory paths
 through time and space, without needing to wrap all the instances it
 creates with faux Date instances.
 
  If you want to lock down the behavior of getTimezoneOffset, or create
 illusory behavior,
 
  Mark wants to do this from JS, not from under the hood (usually via C++)
 using VM internal APIs.

 Sorry, I missed that bit.

 In that case, you'd have to replace the Date function and all Date methods
 that depend on the local time zone: Date as a function; the Date
 constructor for 2 or more arguments; parse; toString  friends;
 getFullYear, getMonth, and their non-UTC friends; getTimezoneOffset,
 setMilliseconds, setSeconds, and their non-UTC friends. That's a lot more
 work, but it still doesn't affect Date instances directly.



*Or* the spec could redefine those functions to use an instance property
lookup which defines the appropriate timezone. I'd suggested this several
months back, and partly for this reason (it's also a much needed feature,
and more idiomatically javascripty). Having Dates depend on an implicit
global timezone is madness. Using a prototype property would allow Date
objects to have their timezone explicitly set or modified, and they'd be
possible to freeze. `Date.prototype.timezone` (or whatever it would be
called) could then float with the system's timezone (or be explicitly set
and/or frozen too). Oh, and this could be cleanly polyfilled to make dates
and timezones suck less today. I still can't think of any downsides.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: How primitive are Symbols? Bignums? etc

[Dean Landolt]

On Mon, Jul 15, 2013 at 12:24 PM, Allen Wirfs-Brock
al...@wirfs-brock.comwrote:


 On Jul 15, 2013, at 8:35 AM, André Bargull wrote:

  Allen (cc-ed) changed symbols back to objects in draft rev 16 (
 https://bugs.ecmascript.org/show_bug.cgi?id=1546#c2), so I guess
 Object(x) will still work in ES6 to test for object types.


 Correct, Symbols as primitive values were just causing too many issues.
  Essentially, everyplace in the spec. that  needs an object had to be
 updated to explicit deal with Symbols.  That certainly isn't a pattern we
 want to follow in the future if add new value types such as bignums. It's
 much cleaner to freeze the set of primitive types and make all future value
 types (including Symbols) objects. just as it would have been even cleaner
 if everything was an object and there were not primitive types.

 Regarding, typeof.  The right way to look at it is that the set of results
 that correspond to non-object types will be fixed and includes only
 (undefined, null, number, string, boolean).  All other typeof
 values correspond of objects (where an object is a value that support the
 ES internal MOP).



I'm very surprised to see null in this list, and not function -- a
typeof typo I hope?
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Why does Array.from accept non-iterable arraylikes?

[Dean Landolt]

On Fri, Jun 28, 2013 at 9:59 AM, Jason Orendorff
jason.orendo...@gmail.comwrote:

 On Thu, Jun 27, 2013 at 1:04 PM, Dean Landolt d...@deanlandolt.com
 wrote:
  On Thu, Jun 27, 2013 at 11:56 AM, Jason Orendorff
  jason.orendo...@gmail.com wrote:
  If you mean a library function that expects either an iterable or a
  dictionary, then it would correctly treat your non-iterable data
  object as a dictionary. So... I guess I don't see the problem.
  Everything seems fine.

 Dean, I would appreciate a response to this. An example of a specific
 case where there would be an actual problem would help the
 conversation tremendously.

  Surely length is a more common database column name than iterator.
  So if you're right, surely we already have these problems with
  existing library functions that take arraylike objects. Is that the
  case? Are there confusing bug reports and hacked-in fallbacks?
 
  Apples and oranges -- people don't use arrays as maps.

 People won't use iterables as maps either; the kind of maps we are
 talking about are ObjectLiterals, and they are not iterable. (You can
 iterate over their properties, though, using a 4-line generator or
 Object.keys().)

 The reason I brought up that example is that people *do* use objects
 with .length properties as arraylikes, leading to potential ambiguity
 about whether an object with a .length property is a plain-Object map
 or an arraylike. I thought perhaps that was the sort of confusion you
 were concerned about.


You've got bigger problems if you're trying this -- the language defines
semantics for `length` on strings and arrays -- generic code would be
foolish to try and go further. But this example does in fact kill my
argument (see below).

An aside -- yes, in my ideal world there would be a unique symbol that
stood in for the `count` of a thing (how many distinct `items` it has).
More than one, in fact, since there are competing notions of counts on the
same kind of thing. If designed carefully this kind of approach could go a
long way toward cleaning up the notion of types in javascript...but I'm way
off topic...


  Perhaps a better example would be `hasOwnProperty`
  -- I know there have been bug reports. The MDN page goes out of its way
 to
  warn about this [1]:

 This is a problem because .hasOwnProperty is an operation that people
 naturally want to apply to plain-Object maps.

 .iterator() is not, because plain Objects are not iterable.


I was missing this detail -- I remember the discussion around this but for
some reason was assuming a different design with a default iterator on
Object.prototype, and the built-in iterator methods deferring to this).
Admittedly this weakens my arguments. But I still wonder how the actual
built-in iterators are expected to be shimmed (without shimming a whole
module system)? From this thread I believe *this* is the core problem that
has yet to be addressed. If solved it would also make system symbols much
less inconvenient for polyfills.

From this perspective it seems unnecessary to, umm, pee in the namespace
pool. But yeah, my strongest arguments for iterator-as-symbol are pretty
well mooted :)
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Why does Array.from accept non-iterable arraylikes?

[Dean Landolt]

On Thu, Jun 27, 2013 at 11:56 AM, Jason Orendorff jason.orendo...@gmail.com
 wrote:

 On Wed, Jun 26, 2013 at 7:54 PM, Dean Landolt d...@deanlandolt.com
 wrote:
  On Wed, Jun 26, 2013 at 6:10 PM, Jason Orendorff 
 jason.orendo...@gmail.com
  wrote:
   What if iterator is present but not a function? Do you walk
   the prototype chain anyway? Blow up? Punt and lookup an iterator
   directly
   based on a mapping with some type testing? [...]
 
  Well, no, it should be treated like any other non-iterable object.
 
  Oh? I know I've personally created boolean database columns named
 iterator
  -- I'm sure I'm not alone. I pity the poor ORM user that tries to pass
 their
  objects to a library function which tries to iterate without fallback. Of
  course we know what's going to happen -- confusing bug reports will
 pressure
  library authors to hack in fallbacks, or just skip the unstratified
 iterator
  call entirely. Do you disagree? How else do you see libraries handling
 this
  specific case?

 I think I disagree, but I'm afraid I don't fully appreciate your point yet.

 If you mean a library function that expects either an iterable or a
 dictionary, then it would correctly treat your non-iterable data
 object as a dictionary. So... I guess I don't see the problem.
 Everything seems fine.

 Surely length is a more common database column name than iterator.
 So if you're right, surely we already have these problems with
 existing library functions that take arraylike objects. Is that the
 case? Are there confusing bug reports and hacked-in fallbacks?


Apples and oranges -- people don't use arrays as maps. I've seen countless
cases where object keys . Perhaps a better example would be
`hasOwnProperty` -- I know there have been bug reports. The MDN page goes
out of its way to warn about this [1]:

JavaScript does not protect the property name hasOwnProperty; thus, if the
possibility exists that an object might have a property with this name, it
is necessary to use an *external* hasOwnProperty to get correct results ...

That's right -- MDN goes out of its way to recommend
`Object.prototype.hasOwnProperty.call`. This is *exactly* what I fear. It's
not a huge loss for hasOwnProperty (or toString) -- experienced JS devs
just accept the fact that polymorphism can't be counted on for these
properties. It would be tragic for this fate to befall `iterator`
polymorphism. In part because it's unnecessary, but also because
polymorphism is central to iterator's usefulness (which I know you agree
about, otherwise you wouldn't be arguing so forcefully against symbol-based
keys).

[1]
https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Object/hasOwnProperty
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Why does Array.from accept non-iterable arraylikes?

[Dean Landolt]

On Wed, Jun 26, 2013 at 6:23 AM, Claude Pache claude.pa...@gmail.comwrote:


 Iterables are useful not only in for/of loops but also in otherwise
 polyfillable constructs; for example, in the Set constructor:

 // Let `a` be a Set object
 b = new Set(a) // copy the elements of `a` into a new Set

 Question: Will there be a standard way for obtaining the @@iterator symbol
 for use in JS code? If so, let say that it is called `GetIteratorSymbol()`;
 then in pre-ES6 environments, we could define:

 function GetIteratorSymbol() { return '__iterator__' }

 and implement/polyfill the iteration protocol in both old and new
 environments, using `GetIteratorSymbol()` where @@iterator is needed. If
 that `GetIteratorSymbol()` function is readily available in a standard
 place, it will allow different libraries to cooperate.



This is very similar to what I suggesting yesterday, though perhaps a
little less noisy. I was beating around the Object.[get|set]IteratorOf bush
but something like Object.getIteratorKey would solve the polyfill interop
problem with just one addition to a system builtin. Perhaps
Reflect.getIteratorKey would be a better place.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Why does Array.from accept non-iterable arraylikes?

[Dean Landolt]

On Wed, Jun 26, 2013 at 9:38 AM, Jason Orendorff
jason.orendo...@gmail.comwrote:

 On Tue, Jun 25, 2013 at 9:36 PM, Brandon Benvie bben...@mozilla.com
 wrote:
  I think that the iteration protocol falls under the type of thing that is
  better exposed through this layer of faux-stratification rather than
  completely unstratified, due to its primary use in supporting syntax
  (for-of). The reason there's any argument against it is because, unlike
 most
  of the other extension points, there's some amount of manually cranking
 the
  wheel that can be useful with the iteration protocol.

 The main use of the iterable protocol is as a contract between a
 function and its caller: a function may expect an iterable for an
 argument, and the caller has the flexibility of passing a great many
 different things.

 The value of this protocol, and the language features supporting it,
 is determined by how much user code is written to take advantage of
 it. There's a network effect. If everyone uses the iterable protocol,
 it's great. The more objects and APIs don't support it, the worse it
 is.

 This means that making the protocol accessible to programmers now
 makes it, and its supporting syntax, much more useful in the future,
 to the degree programmers choose to pre-populate the world with
 iterable objects and APIs that consume them. This is about the end
 state, not the short term.


I completely agree, and would just add that this argument generalizes to
many new es6 features that would be polyfillable *but for...*


 Aside from all that... I get your argument, but I can't help feeling
 that, practically, iterator() is a lot less meta and more user-level
 than the other features. It's one thing if a feature hooks into
 property access. iterator() is just a method.


I assume the primary reason to hang the iterator reference directly off an
object is so that it can be prototypally overloaded -- would you agree?
Given that library code tends toward being as generic as possible, I can
just picture the schism in approaches for looking up the Right iterator. It
won't take long before you start seeing branching for typeof iterator !=
'function' (or even deeper feature tests on the iterator return value).
There will be a schism between factions that walk up the prototype chain
applying this same silly logic and those that go strait for their own
iterator. This is inevitable and will create interop headaches *and* make
it harder to count on reliable prototypal overloading of iteration.

This is the crux of my complaint about the plain `iterator` key, and I
don't think it's been addressed yet.

[snipped the rest]
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Why does Array.from accept non-iterable arraylikes?

[Dean Landolt]

On Wed, Jun 26, 2013 at 12:15 PM, Jason Orendorff jason.orendo...@gmail.com
 wrote:

 On Wed, Jun 26, 2013 at 10:20 AM, Dean Landolt d...@deanlandolt.com
 wrote:
  I assume the primary reason to hang the iterator reference directly off
 an
  object is so that it can be prototypally overloaded -- would you agree?

 Sure. Polymorphism, therefore a method.

  Given that library code tends toward being as generic as possible, I can
  just picture the schism in approaches for looking up the Right iterator.

 If we make the name just plain iterator, there's a conventional
 right answer for this: `typeof obj.iterator === function`.


Yes -- my point about the schism is what libraries will decided to do when
that test fails. What if iterator is present but not a function? Do you
walk the prototype chain anyway? Blow up? Punt and lookup an iterator
directly based on a mapping with some type testing? What kind of type
testing? If this is easy to avoid, why *not?*


 See the
 tests for .toString and .valueOf methods in [[ToPrimitive]] (now
 OrdinaryToPrimitive in ES6[1]), the test for a .toJSON method in [2],
 and the test for .then in DOM Promises.[3]



I strongly suspect the language will evolve these into legacy warts, but as
far as I know when these were introduced there weren't bodies of code that
would obviously blow up (except [3] , but I'll get to that), and if they
were, that blood was spilled long ago. I've come across quite a bit of code
that treat objects as maps. Yes, I know we real maps now, and that's great,
but authors of generic library code can't just cross their fingers and hope
downstream users will do the Right Thing. They'll avoid iterators entirely,
or if not, they'll certainly have to skip the `iterator` method lookup if
they want to avoid weird bug reports. That's a fail.

And yes, [3] will be a completely unnecessary mistake if allowed to stand,
and for similar reasons. Assuming the system module could act as a
namespace for branding keys it's completely incomprehensible to my why the
Promises/A+ folks would be unwilling to add an attempted lookup for this
brand as a synonym for `then` to their spec. This is what I'd proposed as
Promises/A++, but nobody seemed terribly interested. But the `then`
ducktest has no place in the web platform -- it's nothing but a hazard. But
that's a rant for another thread.



 If it's a symbol, it appears `obj[iteratorSymbol] !== undefined` is
 what the spec is doing, at least in one place, the test for a
 .@@ToPrimitive method in [1].

   [1]: https://people.mozilla.com/~jorendorff/es6-draft.html#sec-9.1.1
   [2]: https://people.mozilla.com/~jorendorff/es6-draft.html#sec-15.12.3
   [3]: http://dom.spec.whatwg.org/#promises-model

 Note that IsCallable(obj) is the same thing as `typeof obj ===
 function`. [4], [5]

   [4]: https://people.mozilla.com/~jorendorff/es6-draft.html#sec-9.2.2
   [5]: https://people.mozilla.com/~jorendorff/es6-draft.html#sec-11.4.3

 Of course existing code on the Web uses every possible flavor of
 type-test, and always will, whether the iterator method name is a
 string, a symbol, or a suffusion of yellow. Schism isn't the word.
 Free-for-all maybe.


I think you may have missed my point about where the schism is. I hope I've
made it more clear above and in prior posts but to restate: the schism
isn't the ducktest, it's that the ducktest isn't a *quite* a predicate --
sometimes it can fail in a way where you may want to proceed up the
prototype chain (or do something else). This is where I believe there are
interop landmines buried.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Why does Array.from accept non-iterable arraylikes?

[Dean Landolt]

On Wed, Jun 26, 2013 at 1:31 PM, Brendan Eich bren...@mozilla.com wrote:

 Dean Landolt wrote:

 sometimes it can fail in a way where you may want to proceed up the
 prototype chain (or do something else). This is where I believe there are
 interop landmines buried.


 How is this different from toString?



High-integrity generic code sidestes this problem by deferring to
Object.prototype.toString.call, the consequence being that you can never
really *rely* on a toString override. We make do, sure, but it sucks.
There's no good reason we should have to pay this price for iterable --
especially when the language is finally delivering *exactly* what's needed
(unique symbols) to avoid this issue going forward.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Why does Array.from accept non-iterable arraylikes?

[Dean Landolt]

On Wed, Jun 26, 2013 at 6:10 PM, Jason Orendorff
jason.orendo...@gmail.comwrote:

 On Wed, Jun 26, 2013 at 12:15 PM, Dean Landolt d...@deanlandolt.com
 wrote:
  On Wed, Jun 26, 2013 at 12:15 PM, Jason Orendorff
  jason.orendo...@gmail.com wrote:
  If we make the name just plain iterator, there's a conventional
  right answer for this: `typeof obj.iterator === function`.
 
  Yes -- my point about the schism is what libraries will decided to do
 when
  that test fails.

 If the test returns false, then the object is not iterable.

  What if iterator is present but not a function? Do you walk
  the prototype chain anyway? Blow up? Punt and lookup an iterator directly
  based on a mapping with some type testing? [...]

 Well, no, it should be treated like any other non-iterable object.



Oh? I know I've personally created boolean database columns named
iterator -- I'm sure I'm not alone. I pity the poor ORM user that tries
to pass their objects to a library function which tries to iterate without
fallback. Of course we know what's going to happen -- confusing bug reports
will pressure library authors to hack in fallbacks, or just skip the
unstratified iterator call entirely. Do you disagree? How else do you see
libraries handling this specific case?

Spelling it `iterator` will *work*, but at what cost? The value of the
protocol is seriously diminished.



 If JS were being designed green-field today, maybe some of us would
 make array.length a symbol, not because it's meta (meaning, it is
 used by some key builtins, notably including Function.prototype.apply)
 and not because programmers might want to write a function that
 accepts an argument that's either an arraylike object or a dictionary.
 Those cases *do* exist, but it's just not a problem. Making .length a
 symbol would be a mistake.



I disagree that it would be an obvious mistake. Perhaps without syntax help
from the language it would. But if there were a convenient syntax to
reference system symbols like these it would be objectively better as a
symbol. But we're not green-fielding javascript, so any
`Array.prototype.length` comparison is nonsensical.

Just because you assert this isn't a problem doesn't make it so. What
you're suggesting cripples the polymorphism win for no particularly good
reason, and for what? To avoid defining some kind of mapping between system
modules and the pre-es6 primordials? I contend that this mapping is
inevitable...

If I have it right the crux of your argument is that using a string key
makes this feature more polyfillable, but where do you propose polyfills
put the iterators from the @iter module? I'm confident that one or more of
of the polyfills will invent some kind of mapping. Can you already hear the
calls for an ad hoc standard? Ugh. Let's end the madness before it starts
and carve out a place for the system modules in the global namespace. I can
imagine a bunch of ways to do this -- but I don't care much about how it
happens.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Why does Array.from accept non-iterable arraylikes?

[Dean Landolt]

On Tue, Jun 25, 2013 at 1:33 PM, Allen Wirfs-Brock al...@wirfs-brock.comwrote:


 On Jun 25, 2013, at 10:19 AM, Anne van Kesteren wrote:

  On Tue, Jun 25, 2013 at 4:58 PM, Jason Orendorff
  jason.orendo...@gmail.com wrote:
  On Tue, Jun 25, 2013 at 10:42 AM, Sam Tobin-Hochstadt 
 sa...@ccs.neu.edu wrote:
  My recollection is that we chose to make `iterator` a symbol because
  we worried about taking the name iterator on lots of existing
  objects.
 
  What kind of existing code would be a problem?
 
  Firefox added Array.prototype.iterator a year ago. It has shipped in
  the release browser, and it's been fine.
 
  E.g. HTMLCollection has named getters. Making it iterable without
  breaking compatibility would be great.
 

 This design discussion really wasn't just about iterator.   In ES6 we have
 various property keys that are hooks deeply into either the semantics of
 core language features:  @@create, @@hasInstance, @@ToPrimitive,
 @@iterator, @@toStringTag, @@isRegExp.

 Anyone plugging into these hooks really should be intentional about what
 they are doing.  Accidentally  doing so my poor name choice may mot be
 disastrous but it is likely to be dificult to debug.   Using a symbol for
 these properties greatly reduces the likelihood of such an accident.

 We could make an exception for iterator, but why?  That just introduces an
 inconsistency in the design.



For properties that are expected to be looked up on object or its prototype
unique symbols are the only way to go. Otherwise library code will end up
littered with the `Class.prototype.method.call` pattern and we'll quickly
lose the ability to coherently overload these methods anyway.

But there's still a huge win to be had in *also* defining hooks for this
kind of functionality as static class methods on the built-ins, at least
for the functionality that could otherwise be polyfilled correctly. Any
functionality defined in this way will be instantly usable on the open web
as soon as it gets the TC39 stamp of approval in Rick's meeting notes.
That's a pretty big win for a very small amount of bloat.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Why does Array.from accept non-iterable arraylikes?

[Dean Landolt]

On Tue, Jun 25, 2013 at 2:16 PM, Brandon Benvie bben...@mozilla.com wrote:

 On 6/25/2013 10:33 AM, Allen Wirfs-Brock wrote:

 We could make an exception for iterator, but why? That just introduces an
 inconsistency in the design.


 I think the motivation was to make it easier to polyfill, but I don't
 think that argument holds for @@iterator. If you're attempting to polyfill
 iteration, then you have to polyfill both ends of it; you have to supply
 both the iterators as well as functions to consume those iterators (since
 you can't polyfill for-of). That means you have control over the protocol,
 and can opt to use something like __iterator__.



You could, but your polyfills probably won't play well with other polyfills
unless TC39 specifies a hook (normative or otherwise). Again, if the
platform were to also define a secondary, static way to get and set an
object's *iterator* a la Object.getPrototypeOf the interop problem is
solved. It's hideous, sure, but it's really only necessary in library code.

It would be a shame of the lack of symbols is the only thing that kept
pre-es6-supporting libraries from using iterators or other code that uses
them.



 __**_
 es-discuss mailing list
 es-discuss@mozilla.org
 https://mail.mozilla.org/**listinfo/es-discusshttps://mail.mozilla.org/listinfo/es-discuss

___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Object.values and/or Object.forEach ?

[Dean Landolt]

The for/of iterators solve this nicely. This is definitely something that
comes up a lot though, and this seems like a very handy cowpath to pave. If
it were spec'd I'd suggest the naming and argument values should align with
the for/of variants.


On Fri, Jun 7, 2013 at 12:57 PM, Andrea Giammarchi 
andrea.giammar...@gmail.com wrote:

 it comes out from time to time devs would like to have `Object.values()`
 as equivalent of `Object.keys()` except the returned array would contain
 values.

 Better than repeated
 `Object.keys(obj).map(function(p){return this[k];}, obj);`
 all over

 but probably less useful than a more generic `Object.forEach(obj,
 callback, thisValue)` where `callback` would receive `(value, key,
 originalObject)` and `thisValue` as context.

 This is consistent with `Array#forEach` and could simplify `for/in` loops
 passing over own enumerable properties only, as keys would do.

 Thoughts ?

 ___
 es-discuss mailing list
 es-discuss@mozilla.org
 https://mail.mozilla.org/listinfo/es-discuss


___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Object.values and/or Object.forEach ?

[Dean Landolt]

That's what I meant by the for/of iterators solve this nicely. I think I
might have accidentally edited away the most important part of that
sentence -- let me try again:

this seems like a very handy cowpath to pave *for polyfills*

This way old code can get the benefit of this painfully common idiom too
(without the more heavyweight preprocessing necessary for polyfilling
import syntax).


On Fri, Jun 7, 2013 at 1:25 PM, Brandon Benvie bben...@mozilla.com wrote:

 On 6/7/2013 10:18 AM, Dean Landolt wrote:

 The for/of iterators solve this nicely. This is definitely something that
 comes up a lot though, and this seems like a very handy cowpath to pave. If
 it were spec'd I'd suggest the naming and argument values should align with
 the for/of variants.


 My impression was that the @dict module solves this as you suggest.

 import { keys, values, entries } from '@dict';

 let obj = { a: 1, b: 2, c: 3 };

 for (let key of keys(obj)) {
   // ['a', 'b', 'c']
 }

 for (let value of values(obj)) {
   // [1, 2, 3]
 }

 for (let [key, value] of entries(obj)) {
   // [['a', 1], ['b', 2], ['c', 3]]

 }
 __**_
 es-discuss mailing list
 es-discuss@mozilla.org
 https://mail.mozilla.org/**listinfo/es-discusshttps://mail.mozilla.org/listinfo/es-discuss

___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: The Paradox of Partial Parametricity

[Dean Landolt]

On Tue, May 28, 2013 at 12:24 PM, Russell Leggett russell.legg...@gmail.com
 wrote:

 On Tue, May 28, 2013 at 9:55 AM, Tab Atkins Jr. jackalm...@gmail.comwrote:

 On Mon, May 27, 2013 at 9:53 AM, Russell Leggett
 russell.legg...@gmail.com wrote:

  On Mon, May 27, 2013 at 11:04 AM, Tab Atkins Jr. jackalm...@gmail.com
  wrote:
  On Mon, May 27, 2013 at 7:29 AM, Russell Leggett
  russell.legg...@gmail.com wrote:
   I'm just going to go ahead and play stupid here. Why is it called
 chain?
   I
   agree one more method doesn't break anyone's brain, but I think the
   confusion comes when it is not clear what a method is for and when
 they
   should use it. Can anyone just try to write a really quick API doc
 for
   chain
   so that someone without knowledge of monads could read it? It should
   hopefully be fairly obvious after reading the doc why the method is
   called
   chain.
 
  Yeah, it's pretty easy - the chain() method lets you chain one
  promise into another - you start with a promise, take a function that
  returns a promise, and return a promise from that.
 
  (Naming abstract operations is hard, but I think chain() is better
  than bind().  This is probably why Haskell spells it =. ^_^)
 
  Technically speaking, though, doesn't then also meet that definition
 (plus
  additional functionality)? I agree that naming abstract operations is
 hard,
  but this just screams to me of a method that would get improperly
  used/confused by developers. It would work like then in some cases, but
  break unexpectedly, etc. Brendan says no name mangling, and sure it
 probably
  shouldn't be too bad, but I think it should be on the burden of chain to
  distinguish itself from then, and not the other way around. ES is
 already
  filled with names like getOwnPropertyDescriptor. For the amount of use
 it
  will get, I'm not sure it's worth a shorter, more cryptic name.

 then works equally well for promises, but I don't think it works for
 arbitrary containers - I think I'd understand array.chain(cb) better
 than array.then(cb).


 I wan't suggesting using then for other containers or replacing chain with
 then, I was suggesting that the definition for chain on promises is a
 little ambiguous with the existence of 'then'. 'chain' chains promises
 together. then also chains promises together, but with some extra stuff.
 It puts developers in the position of wondering, so when should I use
 'then'? Why should I use it instead of 'chain'? Given that 'then' is what
 they'll likely want in 99.9% (sorry for my made up statistic) of
 situations, I think that in the case of promises, it should be on the
 burden of the 'chain' method to distinguish itself from 'then'–to define
 itself in relation to 'then'. I think its rather similar to the discussion
 on arrow functions. = is what someone wants so much more often that - was
 left out. It was still possible, after all, its just normal functions, but
 it was decided that to aid comprehension, we would encourage the happy path.

 I'm not arguing 'chain' be removed. I'm convinced at this point its worth
 including, I'm just debating the method name here. Sorry if it's just
 bikeshedding at this point, but on the face of it, the two methods seem
 hard to distinguish, and while 'chain' might be a better name for some
 hypothetical monadic style, why not leave it up to some library to give the
 method a facelift. The same way that the promise API is being kept light,
 and will likely still be wrapped by things like the Q library for
 additional functionality, I expect some monadic focused library will be
 used if using promises in the monadic style. Worst case scenario, you just
 add an alias on the Promise prototype.



I agree with Russell that `chain` is a little ambiguous when juxtaposed
with `then. Around the time this conversation first kicked up I'd proposed
this API and referred to what Tab calls `chain` as the one-step resolver
function. I still think `resolve` would be a pretty good, reasonably
self-documenting name -- especially compared to `chain`. You can describe
`then` as a recursive `resolve` and the difference should be obvious.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: B.3.1 The __proto__ pseudo property

[Dean Landolt]

Call me crazy but I can picture a world where you have to explicitly shim
in __proto__ (using Object.setPrototypeOf) if you really need it. Not
anytime soon, sure, but maybe one day. Maybe...


On Wed, May 8, 2013 at 5:05 PM, Brendan Eich bren...@mozilla.com wrote:

 Having Object.setPrototypeOf to match Object.getPrototypeOf is nice,
 better for proxies (with necessary changes to them), and polyfillable.

 Take my last note as an attitude adjustment, though. So long as __proto__
 endures, its brevity and legacy uses will tend to propagate its use into
 the future.

 In that light, pushing everything but the object literal __proto__ special
 form into Annex B still rubs me the wrong way. I'd do both O.p.__proto__
 and the special form in the main spec, or both in Annex B (to make Andreas
 happy ;-). Not split them up.

 /be


 Allen Wirfs-Brock wrote:

 On May 8, 2013, at 8:46 AM, Andreas Rossberg wrote:

  On 8 May 2013 17:41, Allen 
 Wirfs-Brockallen@wirfs-brock.**comal...@wirfs-brock.com
  wrote:

 On May 8, 2013, at 8:31 AM, Mark Miller wrote:

  What about your triangle argument?

 There is another way:

 let obj = Object.setPrototypeOf({x:0, y:0}, pointProto};

 Let's keep {__proto__: foo} in the slightly  disrespectable  Annex B
 box.  That keeps it together with O.p.__proto and leaves room for future,
 more elegant object literal syntax extensions if we decided we really need
 them (and we probably won't).

 Isn't Object.create the proper alternative to both {__proto__: } and
 triangle for objects? What has setPrototypeOf got to do with it? (And
 why is that on the table all of a sudden?)


 I think that Brandon Benvie adequated addressed Object.create.

 Regarding setPrototypeOf, once Mark agreed that the [[protoSetter]]
 function did not need to be Realm restricted it essentially became a
 publicly available API for modify the [[Prototype]] of arbitrary objects.

Object.**getOwnPropertyDescriptor(**Object.prototype,
 __proto__).set.call(obj, proto)

 There is a vocal part of the JS community who would prefer that the core
 language also offer Object.setPrototypeOf as the preferred alternative to
 the above:

 Object.setPrototypeOf(obj,**proto)

 This is only a cosmetic difference. But I agree that it is good
 cosmetics. Dynamic prototype modification seems to have won as a required
 feature of the language.  Since that is the case, consistancy suggests that
 we should  treat it cosmetically just like all the dynamic reflection
 operations defined on Object.

 Allen









  __**_
 es-discuss mailing list
 es-discuss@mozilla.org
 https://mail.mozilla.org/**listinfo/es-discusshttps://mail.mozilla.org/listinfo/es-discuss

___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: __defineGetter__ returns

[Dean Landolt]

On Tue, May 7, 2013 at 10:13 AM, Rick Waldron waldron.r...@gmail.comwrote:


 On May 7, 2013 3:49 AM, David Bruant bruan...@gmail.com wrote:
 
  Hi,
 
  The latest rumors [1] suggest that __defineGetter__ will be in IE11.

 Of course to benefit platform compatibility, but that doesn't mean ES6 (or
 ES.any) will standardize an obsolete feature alongside its superior
 replacement. ;)


So there's no need to standardize __proto__ then, eh? ;)

/troll
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: __defineGetter__ returns

[Dean Landolt]

On Tue, May 7, 2013 at 11:59 AM, Rick Waldron waldron.r...@gmail.comwrote:




 On Tue, May 7, 2013 at 10:21 AM, Dean Landolt d...@deanlandolt.comwrote:




 On Tue, May 7, 2013 at 10:13 AM, Rick Waldron waldron.r...@gmail.comwrote:


 On May 7, 2013 3:49 AM, David Bruant bruan...@gmail.com wrote:
 
  Hi,
 
  The latest rumors [1] suggest that __defineGetter__ will be in IE11.

 Of course to benefit platform compatibility, but that doesn't mean ES6
 (or ES.any) will standardize an obsolete feature alongside its superior
 replacement. ;)


 So there's no need to standardize __proto__ then, eh? ;)

 /troll


 Perhaps you should actually read the existing discussion and meeting
 resolutions?


I read them religiously, along with es-discuss, and because of this I was
just noting the parallel in reasoning. But I was mostly joking -- note the
/troll tag! :D


 __define|lookup(Getter|Setter)__ have already been standardized in the
 form of the superior Object.definePropert(y|ies) APIs. When the object meta
 APIs were specified, there was little support for the dunder APIs, which
 made it easier to kill them. Since then, __proto__ implementation has
 spread, which means it's _not_ easy to kill—which is why it's being
 standardized. Note that TC39 isn't specifying two different mechanisms
 either, ie. no setPrototypeOf.


TC39 already specifies the other dunders in Annex B. That's where I think
__proto__ belongs. See Mark's recent comment about setPrototypeOf in recent
posting -- no objection to setPrototypeOf is a pleasant surprise!
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: __defineGetter__ returns

[Dean Landolt]

Are they not in the es6 draft yet? I was going by what you'd said a half
hour ago:

These are already in the ES6 spec in fact, under Annex B (normative
 optional).


Regardless, this seems like the perfect place for all of the duners, IMHO.


On Tue, May 7, 2013 at 12:12 PM, Brandon Benvie bben...@mozilla.com wrote:

 On 5/7/2013 9:09 AM, Dean Landolt wrote:

 TC39 already specifies the other dunders in Annex B.


 Not currently. With IE11 adding them, though, it would make sense to add
 them to Annex B.

 __**_
 es-discuss mailing list
 es-discuss@mozilla.org
 https://mail.mozilla.org/**listinfo/es-discusshttps://mail.mozilla.org/listinfo/es-discuss

___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: A Challenge Problem for Promise Designers

[Dean Landolt]

On Fri, Apr 26, 2013 at 11:18 AM, Andreas Rossberg rossb...@google.comwrote:

 On 26 April 2013 16:25, Dean Landolt d...@deanlandolt.com wrote:
  The fundamental controversy, as Juan just noted, is how to precisely
  identify a promise in order to do either of these two things. This
 problem
  isn't quite so clean cut, but it's much more important to solve. I've
 been
  trying to bring some attention to it over the last few days -- I hope
 it's
  clear that a `then` method is not enough to identify a promise language
  construct -- this will subtly break existing code (e.g. casperjs).

 Let me note that this is not the fundamental controversy (not for me,
 anyway). The fundamental controversy is whether there should be any
 irregularity at all, as is unavoidably introduced by implicit
 flattening. The problem you describe just makes the negative effect of
 that irregularity worse.



It may be a little late (I'm just catching up on these promise megathreads)
but I was suggesting that the irregularity posed by flattening is only a
distraction. AFAICT you're concern with flattening is actually in regard to
resolution semantics, right? Otherwise it's unobservable whether you have a
Promisevalue or a PromisePromisevalue. I'm trying to argue that given
a reliable branding a one-step resolver is easy and sensible to define (no
flattening), and a recursive resolver is an obvious extension. Almost
everyone would use the latter, but I completely agree that the former is
necessary too. No irregularities, everybody wins.

I don't think I've been able to properly communicate the gravity of the
branding issue. I'll try code:


  getAFuture()
.then(function(x) {
  return require('casper').create();
});


Assuming you know that factory returns a Casper instance, you would
probably expect a PromiseCasper value, right? But Casper instances have
`then` methods, so it'll quack like a promise to the Promises/A+
assimilation algorithm, so what gets returned will be a Promiseundefined
value. You may luck out and notice some non-sensical behavior, but it's
very possible this code could *almost* work just fine -- right until it
doesn't. It's more than just a debug hazard -- this kind of code could
easily slip into production even with awesome test coverage.

Casper's just a convenient example -- this problem applies to all
thenables that aren't Promises/A+ promises. What's worse, the semantics
of the word `then` imply that many of these thenable objects will probably
*almost* work in the same way as the example above.


To my mind the question of flattening sorts itself out as soon as you
define a means to reliably identify a promise. But it could also be
sidestepped completely, which I believe is the option Dave Herman favored
at one point...

It's been a few years but I recall an exchange we had where he took the
position that there shouldn't even be a method to test whether a value is a
promise -- IIRC he was arguing that any `value | Promisevalue`
functionality was unnecessary, and even hazardous. I was never clear on
exactly how this could be made to work, especially in interoperable
libraries, but as a language construct I suppose it's feasible. I'm curious
to hear where Dave stands now -- he eventually built support for thenables
into task.js (which I think was what sparked this exchange) but that could
have been out of convenience. Of course, with this approach I can't imagine
how promises could possibly be made nestable with one-step resolution (what
people seem to be calling monadic now?).
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: A Challenge Problem for Promise Designers

[Dean Landolt]

On Fri, Apr 26, 2013 at 9:36 AM, David Bruant bruan...@gmail.com wrote:

 Le 26/04/2013 14:54, Kevin Smith a écrit :

 What exactly is the controversy here?

 I think we all agree with the semantics of then as specified in
 Promises/A+.  (If not, then we have a really big problem!)

 If so, then the only real controversy is whether or not the API allows
 one to create a promise whose eventual value is itself a promise.  Q does
 not:  it provides only resolve and reject.  DOM Futures do by way of
 Future.accept.  As far as I know, there's nothing about Q's
 implementation that would make such a function impossible, it just does not
 provide one.

 I believe at this point the question isn't so much can I build a promise
 for a promise?, but rather what should be the default Future semantics?
 Namely:

 Future.accept(5)
 .then(function(x){
 return Future.accept(x);
 })
 .then(function(y){
 // is y a Future?
 })

 I'm arguing in favor of y being guaranteed to be a non-Future value. It is
 my understanding others would want y to be a Future.
 That would be the controversy as I understand it.



Reframing this in terms of resolution semantics may be helpful. I think
others would want a way to resolve one promise without recursively
resolving them all. That doesn't mean that the default resolution semantics
can't recursively resolve. Recursive resolve can be built on top of a
single-step resolver, but even so, it would be useful to also provide (and
recommend) recursive resolve resolve since it has the resolution semantics
demanded by the vast majority of use cases.

The fundamental controversy, as Juan just noted, is how to precisely
identify a promise in order to do either of these two things. This problem
isn't quite so clean cut, but it's much more important to solve. I've been
trying to bring some attention to it over the last few days -- I hope it's
clear that a `then` method is not enough to identify a promise language
construct -- this will subtly break existing code (e.g. casperjs).

In passing people keep assuming a well-known symbol could solve this
problem, but haven't offered any ideas for compatibility with es5 code. I
can't see how we could shim enough of the module system to use it as a
registry here, but maybe we could hang a symbol of a built-in Promise class
that could be shimmed as a random string. Given a built-in Promise class I
believe an `instanceof` branding could be made to work in a shimmable
manner too, with __proto__ hacking getting you the rest of the way there if
it really comes to it (es5 cross-frame wackiness, for instance).
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: A Challenge Problem for Promise Designers

[Dean Landolt]

On Fri, Apr 26, 2013 at 3:47 PM, Domenic Denicola 
dome...@domenicdenicola.com wrote:

 From: David Bruant [bruan...@gmail.com]

  Which naturally leads to the question: why should platform promises be
 compatible with Promise/A+ and not jQuery promises? Because more
 libraries use Promise/A+? what about market share?

 What we're discussing is not *compatibility* but *ability to assimilate*.


The ability to assimilate stems directly from a need for library
compatibility. Seriously -- ask Kris Kowal who twisted his arm into having
Q accept thenables? :P


 Assimilating thenables requires no particular spec compliance or library
 compatibility. Promises/A+ (in the 1.1 version) gives a step-by-step
 procedure for doing so that is quite resilient in the face of edge cases,
 and so I'd recommend it for any assimilation semantics, but that's not
 terribly relevant to the question of whether there should be assimilation
 semantics *at all*.


What I'd really like to know is what is supposed to happen when a casper.js
[1] instance is returned by a promise? There is a lot of this code in the
wild. It's one thing when we're just talking about libraries which users
intentionally choose. But baking these assimilation semantics into the
language will create subtle interactions that are non-trivial to find and
debug. And for what? Compatibility with existing Promises/A+ libraries that
could easily make themselves compatible in other ways? That hardly seems
worth it.

[1] http://casperjs.org/
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: ES6,ES7,ES8 and beyond. A Proposed Roadmap.

[Dean Landolt]

On Wed, Apr 24, 2013 at 11:04 AM, Anne van Kesteren ann...@annevk.nlwrote:

 On Sun, Apr 21, 2013 at 5:21 AM, Mark S. Miller erig...@google.com
 wrote:
  Thoughts?

 I was wondering when operator overloading is planned. It would be
 great to be able to do things like new URL(http://example.org;) ==
 new URL(http://example.org/;).



I'm not sure if there are any plans for overloading but value objects [1]
will solve the specific use case you gave.

[1] http://wiki.ecmascript.org/doku.php?id=strawman:value_objects
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Futures (was: Request for JSON-LD API review)

[Dean Landolt]

On Wed, Apr 24, 2013 at 2:18 PM, Tab Atkins Jr. jackalm...@gmail.comwrote:

 On Wed, Apr 24, 2013 at 10:51 AM, Domenic Denicola
 dome...@domenicdenicola.com wrote:
  From: Andreas Rossberg [rossb...@google.com]
  Mark, could you summarize the rationale for this, or provide a more
 specific link to the appropriate bit of the discussion you are referring to?
 
  I'm not Mark, and he might have something more specific in mind, but
 this summary was pretty helpful:
 
  https://gist.github.com/ForbesLindesay/5392612

 These aren't very good reasons, unfortunately.  :/

 The JQP... problem can be solved by a single flatten operation added
 to the API.  This is a totally reasonable operation, same as it would
 be for Arrays.



I'll do you one better and suggest the JQP... problem can go away
completely the day TC39 decides on a built-in -- let's call it `Promise`
for the sake of argument. A new spec, call it Promises/A++, could then be
defined which states that this class is to be included in the proto chain
of compatible promises. For the sake of interoperable shimming libraries
should create this global if it doesn't exist (this part's a little sketchy
but I can't think of a good alternative that doesn't involve abusing
__proto__).

Now, instead of a ducktest for a `then` method the promise check would
instead be specified as `instanceof Promise`. For the sake of backward
compatibility libraries can choose to add a Promise.prototype.then so that
these new promises work with old promise libs too. If it comes comes to it,
old promises can be made to work in the new regime with a little __proto__
hacking.

The only reason thenables won is because library authors didn't have a
formal namespace to hang these things. This is what ultimately made
assimilation necessary, and it's a non-issue as soon as TC39 specifies a
Promise base class.

[snipped the rest, but FWIW I totally agree w/ Tab]
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Futures

[Dean Landolt]

On Tue, Apr 23, 2013 at 4:54 AM, David Bruant bruan...@gmail.com wrote:

 Le 22/04/2013 19:32, Dean Landolt a écrit :

  I was just saying there will be pressure to include support for thenables
 (already in DOMFutures). If you believe otherwise don't let me dissuade you
 -- I would absolutely love it if I were proven wrong!

 I guess it would take making sure no content can be confused by the
 current steps 3-5 of the current resolve spec [1]. I believe browser
 vendors have tools to study this kind of things.

 CasperJS [2] create objects with a then method [3]. Interestingly, this
 doesn't run in the browser (until someone decides to re-implement it of top
 of a web browser or FirefoxOS. [4] ?). Potentially more interestingly,
 Casper objects could be promises subclasses (to be considered).
 It wouldn't be surprising if there were content on the web where the
 promise subclass trick couldn't work.



What do you mean by the promise subclass trick? If you mean that Casper
instances would subclass Promise I don't think that'd work out too well as
is. Promises/A (and I presume A+) intentionally specified `then` to return
a new promise, so Casper would have to change in a very breaking way to
pull this off.


In any case, considering that an object with a 'then' function is a promise
 is a recipe for confusion. Promise/A+ folks asked for and are happy about
 it. The rest of the webdevs who aren't aware of this subtle non-intuitive
 rule will have a very hard time when, for whatever reason, they have a
 'then' function in a resolve value and their code really behaves in a way
 they don't understand.



I agree it's a recipe for confusion. But the weight of legacy code (growing
by the day) may be too much to bear. Hopefully not -- it's really very
simple for Promises/A+ libs to add `then` to the Promise prototype.


I don't think in the entire platform there is a precedent of doing this
 (maybe for a good reason?). We'll see what web browsers end up implementing.



IMHO __proto__ is one precedent -- and we know how that's going :P
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Futures

[Dean Landolt]

On Tue, Apr 23, 2013 at 9:12 AM, David Bruant bruan...@gmail.com wrote:

  Le 23/04/2013 14:56, Dean Landolt a écrit :

 On Tue, Apr 23, 2013 at 4:54 AM, David Bruant bruan...@gmail.com wrote:

 Le 22/04/2013 19:32, Dean Landolt a écrit :

  I was just saying there will be pressure to include support for
 thenables (already in DOMFutures). If you believe otherwise don't let me
 dissuade you -- I would absolutely love it if I were proven wrong!

  I guess it would take making sure no content can be confused by the
 current steps 3-5 of the current resolve spec [1]. I believe browser
 vendors have tools to study this kind of things.

 CasperJS [2] create objects with a then method [3]. Interestingly, this
 doesn't run in the browser (until someone decides to re-implement it of top
 of a web browser or FirefoxOS. [4] ?). Potentially more interestingly,
 Casper objects could be promises subclasses (to be considered).
 It wouldn't be surprising if there were content on the web where the
 promise subclass trick couldn't work.



  What do you mean by the promise subclass trick? If you mean that Casper
 instances would subclass Promise I don't think that'd work out too well as
 is. Promises/A (and I presume A+) intentionally specified `then` to return
 a new promise, so Casper would have to change in a very breaking way to
 pull this off.

 I'm not sure it would be a breaking change for the vast majority of
 people. They may actually like that instead of being forced to to
 casper.start. They may also enjoy being able to chain .then-s. But maybe
 it's breaking.


IIRC you can already chain thens -- the break is that you will be forced to
chain thens in order to maintain your intended chronology. Inheriting from
Promise would suggest all those then calls will be fired in parallel
instead of happening in serial.

Although the only time I tried Casper (~ a year ago) I gave up on it
because I couldn't get this stuff right anyway.


  Anyway, my point was that there exist libraries in which then is a
 function and the object with this function isn't a promise. These libraries
 will end up in a terrible confusion when used with Futures.
 You think you're resolving a future with an object and... oops! the
 built-in Future algorithm confused your object for a promise. Suddenly, not
 only are you not resolving your promise with the value, but your .then
 method is called unexpectedly.


Apologies, I wasn't very clear. I completely agree with this point and was
just trying to reinforce it :)



 In any case, considering that an object with a 'then' function is a
 promise is a recipe for confusion. Promise/A+ folks asked for and are happy
 about it. The rest of the webdevs who aren't aware of this subtle
 non-intuitive rule will have a very hard time when, for whatever reason,
 they have a 'then' function in a resolve value and their code really
 behaves in a way they don't understand.



 I agree it's a recipe for confusion. But the weight of legacy code
 (growing by the day) may be too much to bear.

 What about the weight of legacy non-promise code using then? The best
 thing we can say now is that we know nothing about it and it'd be wise to
 wait until more data on then is available. The Casper example should at
 least worry us. I hope it will be the browser vendors choice.


   Hopefully not -- it's really very simple for Promises/A+ libs to add
 `then` to the Promise prototype.

 Aren't they already doing that? I don't understand your point here.


No, DOMFutures ships with this OOTB. If there were an es Promise or Future
builtin I suspect there would be a lot of pressure to specify it with
`then` on the prototoype to make its instances compatible with existing
Promises/A+ libs. That's the crushing weight of legacy I'm referring to.

What occurred to me is that it really is just a few lines of code for each
of these Promises/A+ libs to add to tack on the prototype `then` without
having to muddy the spec. In hindsight this seems obvious. I wonder why
DOMFutures didn't go this route? It may not be too late.


  I don't think in the entire platform there is a precedent of doing this
 (maybe for a good reason?). We'll see what web browsers end up implementing.



 IMHO __proto__ is one precedent -- and we know how that's going :P

 Once again, __proto__ is not a good comparison. It's already in the
 platform. As far as promises are concerned, the platform has exactly no
 obligation to follow the current Future or an alternative that'll emerge
 tomorrow; no obligation to follow Promise/A+ or whatever else.


You said I don't think in the entire platform there is a precedent of
doing this. I assume by this you meant using a forgeable string key that
could lead to confusion. That is what we were discussing, right? If so I
think __proto__ is a great example. And again, I think it helps make your (*
our*) point :)
___
es-discuss mailing list
es-discuss@mozilla.org
https

Re: Futures

[Dean Landolt]

On Tue, Apr 23, 2013 at 9:37 AM, David Bruant bruan...@gmail.com wrote:

  Le 23/04/2013 15:27, Dean Landolt a écrit :



 In any case, considering that an object with a 'then' function is a
 promise is a recipe for confusion. Promise/A+ folks asked for and are happy
 about it. The rest of the webdevs who aren't aware of this subtle
 non-intuitive rule will have a very hard time when, for whatever reason,
 they have a 'then' function in a resolve value and their code really
 behaves in a way they don't understand.



 I agree it's a recipe for confusion. But the weight of legacy code
 (growing by the day) may be too much to bear.

  What about the weight of legacy non-promise code using then? The best
 thing we can say now is that we know nothing about it and it'd be wise to
 wait until more data on then is available. The Casper example should at
 least worry us. I hope it will be the browser vendors choice.


   Hopefully not -- it's really very simple for Promises/A+ libs to add
 `then` to the Promise prototype.

  Aren't they already doing that? I don't understand your point here.


  No, DOMFutures ships with this OOTB. If there were an es Promise or
 Future builtin I suspect there would be a lot of pressure to specify it
 with `then` on the prototoype to make its instances compatible with
 existing Promises/A+ libs. That's the crushing weight of legacy I'm
 referring to.

 What occurred to me is that it really is just a few lines of code for each
 of these Promises/A+ libs to add to tack on the prototype `then` without
 having to muddy the spec. In hindsight this seems obvious. I wonder why
 DOMFutures didn't go this route? It may not be too late.

 Until it is widely deployed, *everything* is possible. What browsers will
 choose/accept to implement will be the standard.
 And indeed, I believe existing libs could adapt easily to platform Futures
 even if these don't follow Promise/A+.


 True.


   I don't think in the entire platform there is a precedent of doing this
 (maybe for a good reason?). We'll see what web browsers end up implementing.



 IMHO __proto__ is one precedent -- and we know how that's going :P

  Once again, __proto__ is not a good comparison. It's already in the
 platform. As far as promises are concerned, the platform has exactly no
 obligation to follow the current Future or an alternative that'll emerge
 tomorrow; no obligation to follow Promise/A+ or whatever else.


  You said I don't think in the entire platform there is a precedent of
 doing this. I assume by this you meant using a forgeable string key that
 could lead to confusion. That is what we were discussing, right? If so I
 think __proto__ is a great example. And again, I think it helps make your (
 *our*) point :)

 Oh I see. Then yes, in that sense __proto__ is a relevant comparison
 (sorry for the misunderstanding). Though, the confusion for __proto__ is
 less likely because first, most people were aware of it (which really isn't
 clear for promises/A+) and __ is the sign for both be careful and it's
 unlikely to collide with something else which isn't the case for then.



Agreed. And now that it looks like only the unquoted version of __proto__
will be special the analogy pretty much falls apart in es6. Which is
awesome.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: ES6,ES7,ES8 and beyond. A Proposed Roadmap.

[Dean Landolt]

On Sun, Apr 21, 2013 at 9:29 PM, Mark S. Miller erig...@google.com wrote:

 Agreed that Object.freeze does not give you what you need.

 RiverTrail already needs a kind of collection that is transitively
 immutable by construction. They need this for safe data parallelism. But
 the reason they are safe for parallel access within a vat/worker is the
 same reason they would be safe to pass-by-sharing between vats/workers that
 share an address space. And between address spaces, including between
 machines, they would be passed by copy, but without any observable
 difference beyond performance. We should keep this in mind as we proceed on
 the RiverTrail work.



I completely agree with Mark, and would add that there's a lot to be
learned from the kind of transitive immutability employed by clojure's
persistent data structures. Bringing this kind of thing to js could be
pretty straitforward, and IIUC modern js vms already employ this kind of
structural sharing in the form of ropes for string manipulation. If this
kind of primitive could be extended to userland (perhaps in conjunction
with value types) it would be a huge win for concurrency (safe and free to
pass between workers -- no ownership transfer semantics necessary),
parallelism (RiverTrail would eat this up), but it could be an even bigger
win for run-of-the-mill js code.

Persistent immutable data structures would be a big usability improvement
in their own right. In a world where it's just as cheap and convenient to
use immutable structures as it is to depend on side-effects, code that does
this (including your own) would be a whole lot easier to reason about and
would have objectively better security properties. I'd think this alone
would justify their consideration -- but as Mark suggested, they could also
have real performance advantages given RiverTrail or workers.

But I'll double down on that and suggest there are perf wins to be had for
regulation js code w/o any concurrency or parallelism primitives. For
instance, a persistent immutable array primitive backed by something like a
fingertree would have some really interesting characteristics compared to a
standard js array -- efficient splicing, binary search, deque operations,
constant-time reverse, to name a few. And I won't even start on the
amazingly cool things that could be done if you could provide group
calculations for caching in the branches of your tree (except to say that
js devs should be shouting about monoids, not monads!). And of course this
kind of group-theoretical approach could extend naturally to RiverTrail
code as well...

I bring this up because I think these kinds of optimizations and
performance-specific features would be interesting and useful to explore,
but having said all that, I believe the utility of persistent data
structures stands on it's own, regardless of possible perf wins (parallel,
concurrent or otherwise). I would love to see this discussed along with
value types for es7.



 On Sun, Apr 21, 2013 at 3:49 PM, Sam Tobin-Hochstadt sa...@ccs.neu.eduwrote:

 Then consider `Object.freeze(console)`.

 Fundamentally, frozen objects are not appropriate for prohibiting shared
 state.

 Sam

 On Sun, Apr 21, 2013 at 6:44 PM, Kevin Gadd kevin.g...@gmail.com wrote:
  isn't typeof (console.log) function and not object? by object I
 meant an
  Object object, not 'any arbitrary JS value'. I suppose the distinction
 is
  really blurry, and you would still have to deal with problems like the
  object's prototype chain containing callables...
 
 
  On Sun, Apr 21, 2013 at 3:42 PM, Sam Tobin-Hochstadt sa...@ccs.neu.edu
 
  wrote:
 
  On Sun, Apr 21, 2013 at 6:33 PM, Kevin Gadd kevin.g...@gmail.com
 wrote:
   if I called Object.freeze or Object.seal on a JS object would it
   actually be
   safe to pass it to another thread and let both threads use it without
   any
   locking or guards?
 
  No, it's not safe.  Consider Object.freeze(console.log).
 
  Sam
 
 
 
 
  --
  -kg




 --
 Cheers,
 --MarkM

 ___
 es-discuss mailing list
 es-discuss@mozilla.org
 https://mail.mozilla.org/listinfo/es-discuss


___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Futures

[Dean Landolt]

On Mon, Apr 22, 2013 at 10:15 AM, Mark S. Miller erig...@google.com wrote:

 On Mon, Apr 22, 2013 at 5:37 AM, David Bruant bruan...@gmail.com wrote:

  Le 22/04/2013 14:26, Kevin Smith a écrit :


  Thenable futures are uglier than branded futures, but also the only
 way to remain compatible with the various libraries that are out there
 today, which is something many people value.


  What about using a symbol for the `then` protocol?  Libraries can be
 upgraded to use the symbol as an alias for `then`.  It set up a dependency
 on ES6, of course...

 And it doesn't address the compatibility problem people want to address.
 I personally wonder whether the compatibility with existing libraries is
 so important. It should be pretty easy to wrap a native future into a
 library future (aren't native futures already Promise/A+ compatible?) and
 vice versa. Why isn't it enough to help with compatibility with libraries?

 Eventually, what will be the point of a promise library if there is
 native support?


 This is the great irony. Even if standard platform-provided ES promises
 win in the end, there will be a long transition period where there are
 several co-existing libraries. In order for standard platform-provided ES
 promises to win, it has to thrive in the environment of that co-existence.
 If it ever wins definitively, so that there are no remaining libraries of
 concern, it will no longer need the assimilation mechanisms that enabled
 that co-existence; but by then it will be too late to shed it. I would like
 a realistic way out of this dilemma. But after a tremendous number of
 messages on the promises/A+ site about exactly this issue (please read or
 at least skim), I don't think any of the alternatives are realistic. At 
 https://github.com/promises-aplus/promises-spec/issues/94#issuecomment-16244517
 I write:


 The original E promise API which inspired all these others has no
 assimilation. When I first heard about assimilation, I thought it was a
 terrible idea, for many of the same reasons that underlie many of the above
 objections. However, as I saw the JS promise landscape evolve, I despaired
 more over a worse problem:

 Several similar but different elephants in the room: jQuery promises,
 WinJS promises, Q promises, and DOMFutures. All of these but DOMFutures
 have enough installed base that they're not going away. And re DOMFutures,
 never underestimate the ability of the w3c to be an elephant even for
 premature standards. Much code will have to be written in an environment
 inhabited by multiple such promise systems simultaneously. If none of these
 recognize each other's promises as anything promise-like, then programmers
 will face the burden of dealing with a jQuery promise for a Q promise for
 a WinJS promise for a DOMFuture for a number. Call it the
 JQPFAQPFAWJPFADFFAN problem. I didn't see how we could get from that
 situation to one with an agreed standard promise anything.

 Fortunately, the starting point for all of these elephants was so similar
 that the Promises/A+ process was able to tease out and codify a
 common-enough ground for all of these to agree on. This is messy real-world
 standards work; as much politics and sociology as technology and math.
 Given the constraints imposed by legacy, we should all be overjoyed that
 the Promises/A+ community has been able to extract something as beautiful
 as they did. But even if they all agreed on exactly the same spec, so long
 as jQuery promises only recognize jQuery promises as promises, and likewise
 for the others, we would still have the JQPFAQPFAWJPFADFFAN problem.

 Had ES6 with its unique symbols happened long before any of these promise
 libraries, we could have used a unique @then symbol for assimilation and
 so avoided the accidental collision @killdream worries about above.
 Likewise, if all of these had stuck with the E (or original Q) name when
 rather than renaming it then, we would have less accidental collision,
 and would be less irritating to category theorists. (FWIW, I think when
 was a much better term than then for this anyway. I am still unclear on
 the history of how this got renamed.) Alas, it didn't turn out that way.



I may be partly responsible for this -- I think I helped convince Kris
Kowal, who championed the Promises/C proposal (not sure if there was ever a
Promises/B) which only used `when` that the `when` function could not be
made interoperable between libraries because it had to rely solely on
branding checks. This was back before Symbols were even a thing and
__proto__ was considered for standardization. The presence of either would
have cut my argument at the knees.


Given multiple promise systems that each recognize only their own promises
 as promises, but which mostly agree on the meaning of then, assimilation
 turns out to be a surprisingly pleasant way for these to co-exist. Given
 the actual situation we have to start from, having this assimilation be
 based on duck typing on 

Re: Futures

[Dean Landolt]

On Mon, Apr 22, 2013 at 11:16 AM, Domenic Denicola 
dome...@domenicdenicola.com wrote:

 From: David Bruant [bruan...@gmail.com]

  Especially given that it's only for a transitioning period where native
 (or polyfilled) have to cohabit with previous library promises?

 This is a really bad misconception that you have repeated several times
 now.

 DOM Futures, and possibly ECMAScript promises, are practically
 feature-less. They have `then`, `catch` sugar, a few static combinator
 methods, and that's it. If you want to do anything serious with promises,
 you're going to need a lot more than that. Check out the extensive API Q
 provides, for example:

 https://github.com/kriskowal/q/wiki/API-Reference

 In particular, I and teams I have worked on in real-world projects use
 `promise.finally`, the promise-for-object methods, the promise-for-function
 methods, and the utility methods literally every day. (To say nothing of
 the Node.js-interfacing methods.) Features like long stack traces have been
 invaluable for us. When.js has similar extra capabilities beyond the
 basics, and even RSVP (which is pretty lightweight) has `RSVP.hash` for
 shallowly settling any promise properties of an object. And the Q ecosystem
 is built around different fundamental primitives from DOM Futures which
 allow things like promise for remote objects, promise pipelining, and the
 like---use cases which are increasingly important.

 To think that users who are accustomed to this level of flexibility are
 going to suddenly switch to DOM Futures/ECMAScript promises is very naive.
 More likely, those will be used alongside more full-featured promises
 returned from other parts of the system---forever, not just in some
 transition period. Thus, interop is going to be necessary for an ergonomic
 experience.



To be fair I don't think David is suggesting that these libraries won't be
used, just that the kind of promises that are produced and consumed will
coalesce in the presence of a platform standard. And in order for that
standard to solve the primary problem being discussed, `then` would have to
fall by the wayside.

FWIW I disagree with him -- I strongly suspect that by the time this were
to all go down and a stable polyfill existed there'd already be too much
then-demanding code in the wild. There probably already is. And at that
point it's __proto__ all over again -- the standard will have no choice but
to respect then and the problem cannot be fixed :-/
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Futures

[Dean Landolt]

On Mon, Apr 22, 2013 at 1:15 PM, David Bruant bruan...@gmail.com wrote:

 Le 22/04/2013 17:16, Domenic Denicola a écrit :

  From: David Bruant [bruan...@gmail.com]

  Especially given that it's only for a transitioning period where native
 (or polyfilled) have to cohabit with previous library promises?

 This is a really bad misconception that you have repeated several times
 now.

 DOM Futures, and possibly ECMAScript promises, are practically
 feature-less. They have `then`, `catch` sugar, a few static combinator
 methods, and that's it. If you want to do anything serious with promises,
 you're going to need a lot more than that. Check out the extensive API Q
 provides, for example:

 https://github.com/kriskowal/**q/wiki/API-Referencehttps://github.com/kriskowal/q/wiki/API-Reference

 In particular, I and teams I have worked on in real-world projects use
 `promise.finally`, the promise-for-object methods, the promise-for-function
 methods, and the utility methods literally every day. (To say nothing of
 the Node.js-interfacing methods.) Features like long stack traces have been
 invaluable for us. When.js has similar extra capabilities beyond the
 basics, and even RSVP (which is pretty lightweight) has `RSVP.hash` for
 shallowly settling any promise properties of an object. And the Q ecosystem
 is built around different fundamental primitives from DOM Futures which
 allow things like promise for remote objects, promise pipelining, and the
 like---use cases which are increasingly important.

 To think that users who are accustomed to this level of flexibility are
 going to suddenly switch to DOM Futures/ECMAScript promises is very naive.
 More likely, those will be used alongside more full-featured promises
 returned from other parts of the system---forever, not just in some
 transition period. Thus, interop is going to be necessary for an ergonomic
 experience.

 I never suggested to give all that up. In the long term, all of that can
 be re-implemented on top of platform promises (with devtools support which
 is a significant bonus; you were talking about stack traces?) and maybe
 even improved based on the experience of current libraries.
 For the transition period, I suggested:

  Each library can add:
 if(nativeFuture(p))
 p = wrapNativeFuture(p)

 to the beginning each of its method accepting a promise as argument (or
 equivalent is the promise is in 'this')

 These 2 lines (+wrapNativeFuture) sound pretty practical to me for the
 transition period.

 It sounds like a reasonable compromise for libraries to work with built-in
 promises without imposing a burden on top of these.



 Dean Landolt wrote:

 FWIW I disagree with him -- I strongly suspect that by the time this were
 to all go down and a stable polyfill existed there'd already be too much
 then-demanding code in the wild. There probably already is. And at that
 point it's __proto__ all over again -- the standard will have no choice but
 to respect then and the problem cannot be fixed :-/

 There is a major difference with __proto__ which is that it is a platform
 de facto standard not a library de facto standard. __proto__ is already in
 the platform, it makes sense to standardize it as part of the platform.
 .then is a convention among a particular dev community (which I consider
 to be part of, but that's beyond the point); I'm not sure why the platform
 should follow that convention.


It was an imperfect analogy -- I was just saying there will be pressure to
include support for thenables (already in DOMFutures). If you believe
otherwise don't let me dissuade you -- I would absolutely love it if I were
proven wrong!


 By that logic, should the intersection of jQuery and Zepto's $ be included
 in the platform? Or the intersection of Underscore and Lodash for _ (there
 are minor differences)?


Apples and oranges -- these two are globals and have nothing to do with a
ducktyped defacto method.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Futures

[Dean Landolt]

On Mon, Apr 22, 2013 at 12:47 PM, Kevin Smith zenpars...@gmail.com wrote:


  FWIW I disagree with him -- I strongly suspect that by the time this
 were to all go down and a stable polyfill existed there'd already be too
 much then-demanding code in the wild. There probably already is. And at
 that point it's __proto__ all over again -- the standard will have no
 choice but to respect then and the problem cannot be fixed :-/


 Why not?  If the `then` symbol is well-known (e.g. easily imported from
 somewhere), then why can't libraries be upgraded to use it as an alias for
 their `then` method?



I would love to see this, but best I can tell it can't be a straitforward
polyfill. The necessary infrastructure has to settle, and what are
Promises/A+ implementers supposed to do in the meantime?

Unless a reasonably elegant solution can be found I suspect any es promises
proposal will include support for thenables. I spent a lot of time thinking
about it a few years back and couldn't find one, so I remain skeptical.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Futures

[Dean Landolt]

On Mon, Apr 22, 2013 at 1:53 PM, Kevin Smith zenpars...@gmail.com wrote:


  I would love to see this, but best I can tell it can't be a
 straitforward polyfill. The necessary infrastructure has to settle, and
 what are Promises/A+ implementers supposed to do in the meantime?


 Presumably the standard version of Future would provide some convenient
 way to get the symbol.  The library would use that to conditionally provide
 the symbol-named alias.  Something along these lines:

 if (typeof Future !== undefined)
 MyPromise.prototype[Future.thenSymbol] = MyPromise.prototype.then;

 No?



Perhaps, depending on how all the current libs are being used in the wild.
But this assumption does breaks the ducktyping as defined by the spec. Who
knows -- this may not be a problem in practice.

Alternatively it occurs to me that now that we'll have mutable __proto__ to
lean on we could specify something like Promises/A++ as Promises/A+ with
the additional constraint that some Promise (or Future, or whatever)
builtin exist on the proto chain of any promise. This would allow for
instanceof checks to be interoperable across libraries. And really, you
don't even really need mutable __proto__ -- this is only necessary for
pure-userland interoperability. Since this a standard builtin the problems
with Promises/C go away -- even when polyfilled all promise libs could
expect to see the same base class. That is, IIRC -- it's been a *long* time
since I've really chewed this over.

So I guess I'm less skeptical. Promise (and an accompanying Promise.when)
could be defined and shimmed into existing tool chains today. A huge chunk
of currently working Promises/A+ code would break without a corresponding
Promise.prototype.then, but nothing would stop lib authors from adding it.
And even without it the migration path would be straightforward and could
even be automated.

Okay, I'm convinced. But I don't matter -- both TC39 and the Promises/A+
implementers have to be.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Time zone offsets for any time zone, possible change to Date functionality (i18n)

[Dean Landolt]

On Sun, Apr 14, 2013 at 10:49 PM, Norbert Lindenberg 
ecmascr...@lindenbergsoftware.com wrote:


 On Apr 9, 2013, at 15:23 , Nebojša Ćirić wrote:

  I'll add this as a second option to the strawman.
 
 
  2013/4/9 Sorin Mocanu sorinmoc...@google.com
  Thank you Nebojša.
  How about if the [timezone] parameter would only be passed at the
 construction of the Date object? That would (perhaps) allow a user to
 centralize timezone validation as well.
 
  For example:
  var date = Date.withTimeZone(America/Los_Angeles, 2013, 3, 9, 15, 11,
 0);
  var date = Date.withTimeZone(America/Los_Angeles, 1365545496000);
  date.getHours(); // 15
  date.getUTCHours(); // 22

  Sorin Mocanu, Software Engineer
  Google Switzerland GmbH | Brandschenkestrasse 110 | Zurich, Switzerland
 | 8002 Zurich

 I'm afraid this would be quite confusing. Many people believe already that
 Date instances are in some local time zone, which they aren't, and this
 would lead even more astray.



Of course Date instances are in some local timezone -- the timezone of the
host system. This data isn't explicitly carried along with each date --
instead it's just more implicit global state. But it's naive and even
hazardous to pretend a Date instance has no timezone component -- to say
this with a strait face would requiring removing the locale-specific date
methods. *This* is what is leading so many astray. Further, I've found that
changing the host timezone can wreak havoc on this implicit state in some
environments. I couldn't find anything in the spec about expected behavior
but there are subtle but real hazards lurking here.

Previously I'd suggested that Date instances should just own their
timezone. Make explicit what's already there implicitly -- slap the system
timezone as a symbol on Date.prototype and correct all locale-specific date
methods to respect this symbol instead of some hidden global state. Of
course this has no** impact on a date's underlying value, just on the
behavior of its locale methods. If you want to alter the timezone used for
locale methods on a specific instance just set this property. You can get a
Date constructor pinned to a specific timezone through subclassing. Weak
implementations lacking proper tz support would freeze this property on
fresh dates.

All the while *nothing* about Date objects and their methods would change
-- it would be fully backward compatible. With a little more thought it
could be made polyfillable (perhaps it doesn't need to be a symbol at all,
if a suitable name can be found that is unlikely to collide with existing
libs). What's not to like? More specifically, in what way is the current
state of affairs better?

[snipped the rest]
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Time zone offsets for any time zone, possible change to Date functionality (i18n)

[Dean Landolt]

Perhaps I wasn't clear: I was proposing the timezone property as purely
informative for the locale methods. The Date constructor used to revive the
IDB value will dictate the date's timezone, so no, the cloned date wouldn't
carry its timezone with it. However, in my proposed world it would be
possible to create a Date subclass that will serialize a date with its
timezone tag and revive it always frozen to that timezone. This kind of
serialization couldn't be stored directly as a Date in IDB, but that's not
much of a limitation. Same goes for JSON, which doesn't even have a native
Date so you need a custom cons anyway.


On Mon, Apr 15, 2013 at 9:33 AM, Claude Pache claude.pa...@gmail.comwrote:


 Le 15 avr. 2013 à 14:43, Dean Landolt d...@deanlandolt.com a écrit :




 On Sun, Apr 14, 2013 at 10:49 PM, Norbert Lindenberg 
 ecmascr...@lindenbergsoftware.com wrote:


 On Apr 9, 2013, at 15:23 , Nebojša Ćirić wrote:

  I'll add this as a second option to the strawman.
 
 
  2013/4/9 Sorin Mocanu sorinmoc...@google.com
  Thank you Nebojša.
  How about if the [timezone] parameter would only be passed at the
 construction of the Date object? That would (perhaps) allow a user to
 centralize timezone validation as well.
 
  For example:
  var date = Date.withTimeZone(America/Los_Angeles, 2013, 3, 9, 15, 11,
 0);
  var date = Date.withTimeZone(America/Los_Angeles, 1365545496000);
  date.getHours(); // 15
  date.getUTCHours(); // 22

  Sorin Mocanu, Software Engineer
  Google Switzerland GmbH | Brandschenkestrasse 110 | Zurich, Switzerland
 | 8002 Zurich

 I'm afraid this would be quite confusing. Many people believe already
 that Date instances are in some local time zone, which they aren't, and
 this would lead even more astray.



 Of course Date instances are in some local timezone -- the timezone of the
 host system. This data isn't explicitly carried along with each date --
 instead it's just more implicit global state. But it's naive and even
 hazardous to pretend a Date instance has no timezone component -- to say
 this with a strait face would requiring removing the locale-specific date
 methods. *This* is what is leading so many astray. Further, I've found
 that changing the host timezone can wreak havoc on this implicit state in
 some environments. I couldn't find anything in the spec about expected
 behavior but there are subtle but real hazards lurking here.

 Previously I'd suggested that Date instances should just own their
 timezone. Make explicit what's already there implicitly -- slap the system
 timezone as a symbol on Date.prototype and correct all locale-specific date
 methods to respect this symbol instead of some hidden global state. Of
 course this has no** impact on a date's underlying value, just on the
 behavior of its locale methods. If you want to alter the timezone used for
 locale methods on a specific instance just set this property. You can get a
 Date constructor pinned to a specific timezone through subclassing. Weak
 implementations lacking proper tz support would freeze this property on
 fresh dates.

 All the while *nothing* about Date objects and their methods would change
 -- it would be fully backward compatible. With a little more thought it
 could be made polyfillable (perhaps it doesn't need to be a symbol at all,
 if a suitable name can be found that is unlikely to collide with existing
 libs). What's not to like? More specifically, in what way is the current
 state of affairs better?

 [snipped the rest]

 ___
 es-discuss mailing list
 es-discuss@mozilla.org
 https://mail.mozilla.org/listinfo/es-discuss


 Hi Dean,

 What would be the behaviour of the following steps:

 (1) store a Date object `d` locally using IndexedDB;
 (2) change the timezone of the operating system, and maybe restart the
 browser;
 (3) retrieve the date `d` stored in step 1.

 In what timezone will be the retrieved date? and in what timezone should
 it be?

 I have not try the experiment, but my educated guess is that (1) the value
 of`d.getUTCHours()` would remain invariant and (2) the value of
 `d.getHours()` would vary according to the change operated in step (2). In
 other words, `getHours`, `setHours`, etc. do have (unfortunately) an
 implicit parameter, which is the timezone provided by the system, but that
 parameter is not part of the `Date` instance.

 Now, do you propose that `d` should hold its timezone information, so that
 it would remain in the old timezone, but `dCloned = new Date(d)` would be
 in the new timezone? *That* seems hazardous to me.


 —Claude






___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Time zone offsets for any time zone, possible change to Date functionality (i18n)

[Dean Landolt]

On Mon, Apr 15, 2013 at 10:01 AM, Dean Landolt d...@deanlandolt.com wrote:

 Perhaps I wasn't clear: I was proposing the timezone property as purely
 informative for the locale methods. The Date constructor used to revive the
 IDB value will dictate the date's timezone, so no, the cloned date wouldn't
 carry its timezone with it. However, in my proposed world it would be
 possible to create a Date subclass that will serialize a date with its
 timezone tag and revive it always frozen to that timezone. This kind of
 serialization couldn't be stored directly as a Date in IDB, but that's not
 much of a limitation. Same goes for JSON, which doesn't even have a native
 Date so you need a custom cons anyway.



To drive this point home perhaps a suitable key would be `localeTimezone`
to communicate that this is the timezone used by the locale-specific
methods. It's seems unlikely to conflict with popular libraries, but I
could do a quick survey and code search to confirm.




 On Mon, Apr 15, 2013 at 9:33 AM, Claude Pache claude.pa...@gmail.comwrote:


 Le 15 avr. 2013 à 14:43, Dean Landolt d...@deanlandolt.com a écrit :




 On Sun, Apr 14, 2013 at 10:49 PM, Norbert Lindenberg 
 ecmascr...@lindenbergsoftware.com wrote:


 On Apr 9, 2013, at 15:23 , Nebojša Ćirić wrote:

  I'll add this as a second option to the strawman.
 
 
  2013/4/9 Sorin Mocanu sorinmoc...@google.com
  Thank you Nebojša.
  How about if the [timezone] parameter would only be passed at the
 construction of the Date object? That would (perhaps) allow a user to
 centralize timezone validation as well.
 
  For example:
  var date = Date.withTimeZone(America/Los_Angeles, 2013, 3, 9, 15,
 11, 0);
  var date = Date.withTimeZone(America/Los_Angeles, 1365545496000);
  date.getHours(); // 15
  date.getUTCHours(); // 22

  Sorin Mocanu, Software Engineer
  Google Switzerland GmbH | Brandschenkestrasse 110 | Zurich,
 Switzerland | 8002 Zurich

 I'm afraid this would be quite confusing. Many people believe already
 that Date instances are in some local time zone, which they aren't, and
 this would lead even more astray.



 Of course Date instances are in some local timezone -- the timezone of
 the host system. This data isn't explicitly carried along with each date --
 instead it's just more implicit global state. But it's naive and even
 hazardous to pretend a Date instance has no timezone component -- to say
 this with a strait face would requiring removing the locale-specific date
 methods. *This* is what is leading so many astray. Further, I've found
 that changing the host timezone can wreak havoc on this implicit state in
 some environments. I couldn't find anything in the spec about expected
 behavior but there are subtle but real hazards lurking here.

 Previously I'd suggested that Date instances should just own their
 timezone. Make explicit what's already there implicitly -- slap the system
 timezone as a symbol on Date.prototype and correct all locale-specific date
 methods to respect this symbol instead of some hidden global state. Of
 course this has no impact on a date's underlying value, just on the
 behavior of its locale methods. If you want to alter the timezone used for
 locale methods on a specific instance just set this property. You can get a
 Date constructor pinned to a specific timezone through subclassing. Weak
 implementations lacking proper tz support would freeze this property on
 fresh dates.

 All the while *nothing* about Date objects and their methods would
 change -- it would be fully backward compatible. With a little more thought
 it could be made polyfillable (perhaps it doesn't need to be a symbol at
 all, if a suitable name can be found that is unlikely to collide with
 existing libs). What's not to like? More specifically, in what way is the
 current state of affairs better?

 [snipped the rest]

 ___
 es-discuss mailing list
 es-discuss@mozilla.org
 https://mail.mozilla.org/listinfo/es-discuss


 Hi Dean,

 What would be the behaviour of the following steps:

 (1) store a Date object `d` locally using IndexedDB;
 (2) change the timezone of the operating system, and maybe restart the
 browser;
 (3) retrieve the date `d` stored in step 1.

 In what timezone will be the retrieved date? and in what timezone should
 it be?

 I have not try the experiment, but my educated guess is that (1) the
 value of`d.getUTCHours()` would remain invariant and (2) the value of
 `d.getHours()` would vary according to the change operated in step (2). In
 other words, `getHours`, `setHours`, etc. do have (unfortunately) an
 implicit parameter, which is the timezone provided by the system, but that
 parameter is not part of the `Date` instance.

 Now, do you propose that `d` should hold its timezone information, so
 that it would remain in the old timezone, but `dCloned = new Date(d)` would
 be in the new timezone? *That* seems hazardous to me.


 —Claude

Re: Time zone offsets for any time zone, possible change to Date functionality (i18n)

[Dean Landolt]

On Mon, Apr 15, 2013 at 11:46 AM, Norbert Lindenberg 
ecmascr...@lindenbergsoftware.com wrote:


 On Apr 15, 2013, at 5:43 , Dean Landolt wrote:

  On Sun, Apr 14, 2013 at 10:49 PM, Norbert Lindenberg 
 ecmascr...@lindenbergsoftware.com wrote:
 
  I'm afraid this would be quite confusing. Many people believe already
 that Date instances are in some local time zone, which they aren't, and
 this would lead even more astray.
 
 
  Of course Date instances are in some local timezone -- the timezone of
 the host system. This data isn't explicitly carried along with each date --
 instead it's just more implicit global state. But it's naive and even
 hazardous to pretend a Date instance has no timezone component -- to say
 this with a strait face would requiring removing the locale-specific date
 methods. This is what is leading so many astray. Further, I've found that
 changing the host timezone can wreak havoc on this implicit state in some
 environments. I couldn't find anything in the spec about expected behavior
 but there are subtle but real hazards lurking here.

 No, Date instances are in UTC - read the spec.
 https://mail.mozilla.org/pipermail/es-discuss/2013-March/028928.html


I believe you're misunderstanding me.


 The time zone of the host system is, as you say, global state. Confusing
 instance data and global state has real hazards in many areas of software
 development.


You're suggesting that implicit, hidden global state is the right thing?
Can you think of another example in the language of this kind of ambient
state? If there is I bet it'd look like a bug.


  Previously I'd suggested that Date instances should just own their
 timezone. Make explicit what's already there implicitly -- slap the system
 timezone as a symbol on Date.prototype and correct all locale-specific date
 methods to respect this symbol instead of some hidden global state. Of
 course this has no impact on a date's underlying value, just on the
 behavior of its locale methods.

 So which one are you proposing: having Date instances ... own their
 timezone or slap the system timezone as a symbol on Date.prototype and
 correct all locale-specific date methods to respect this symbol? These are
 not the same.


As you've said, the underlying value of a date is UTC. But there are a
bunch of locale-specific methods that depend on a global timezone state.
I'm simply suggesting that instead of this global state it would be better
if these locale-specific methods resolved the appropriate timezone instead
by using an explicit property (using prototypal inheritance for a sane
default). Again, this timezone is not part of the value of a date, and
would not be preserved on copy. It simply codifies something that's already
happening, allowing it to be controlled in an idiomatic way.


  If you want to alter the timezone used for locale methods on a specific
 instance just set this property.

 Changing the property would affect all instances that have Date.prototype
 as their prototype, not just a specific instance.


Sure, if you set the property on Date.prototype, but I didn't say to do
that. Perhaps code will clear things up -- here's an example of using my
proposal and its effects:


Date.prototype.localeTimezone;
// 'America/New_York'
var d = new Date('2013-04-15Z');
// Sun Apr 14 2013 20:00:00 GMT-0400 (EDT)
+d;
// 136598400
d.localeTimezone = 'America/Los_Angeles';
// 'America/Los_Angeles'
d;
// Sun Apr 14 2013 20:00:00 GMT-0700 (PDT)
+d;
// 136598400
var e = new Date(d);
// Sun Apr 14 2013 20:00:00 GMT-0400 (EDT)
Date.prototype.localeTimezone = 'America/Los_Angeles';
e;
// Sun Apr 14 2013 20:00:00 GMT-0700 (PDT)


Only locale-specific methods are affected -- we're just making the global
lookup for timezone into a prototypal one. I can't imagine anything more
idiomatic.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Time zone offsets for any time zone, possible change to Date functionality (i18n)

[Dean Landolt]

On Mon, Apr 15, 2013 at 2:13 PM, Norbert Lindenberg 
ecmascr...@lindenbergsoftware.com wrote:


 On Apr 15, 2013, at 9:23 , Dean Landolt wrote:

  On Mon, Apr 15, 2013 at 11:46 AM, Norbert Lindenberg 
 ecmascr...@lindenbergsoftware.com wrote:
 
  On Apr 15, 2013, at 5:43 , Dean Landolt wrote:
 
   On Sun, Apr 14, 2013 at 10:49 PM, Norbert Lindenberg 
 ecmascr...@lindenbergsoftware.com wrote:
  
   I'm afraid this would be quite confusing. Many people believe
 already that Date instances are in some local time zone, which they aren't,
 and this would lead even more astray.
  
  
   Of course Date instances are in some local timezone -- the timezone
 of the host system. This data isn't explicitly carried along with each date
 -- instead it's just more implicit global state. But it's naive and even
 hazardous to pretend a Date instance has no timezone component -- to say
 this with a strait face would requiring removing the locale-specific date
 methods. This is what is leading so many astray. Further, I've found that
 changing the host timezone can wreak havoc on this implicit state in some
 environments. I couldn't find anything in the spec about expected behavior
 but there are subtle but real hazards lurking here.
 
  No, Date instances are in UTC - read the spec.
  https://mail.mozilla.org/pipermail/es-discuss/2013-March/028928.html
 
  I believe you're misunderstanding me.

 That's always possible. What did I misunderstand, and what did you really
 mean?



I wasn't suggesting Date instances be anything other than UTC. Based on
your other responses below I believe that misunderstanding was cleared up.
Thanks for bearing with me...



  The time zone of the host system is, as you say, global state.
 Confusing instance data and global state has real hazards in many areas of
 software development.
 
  You're suggesting that implicit, hidden global state is the right thing?

 I said no such thing. I only said that it's different from instance data.



Sorry -- I read it as suggesting the current state of affairs was in some
way superior.



  Can you think of another example in the language of this kind of ambient
 state? If there is I bet it'd look like a bug.

 The other example I'm aware of is the default locale, and we addressed
 that by adding locales arguments to the locale sensitive functionality in
 the internationalization API. We similarly addressed the default time zone
 issue by adding a timeZone property in the options argument of
 DateTimeFormat and the Date.prototype.toLocale*String methods, and in the
 latest draft of the internationalization API spec that allows for the
 complete set of IANA time zone names. In this thread, Nebojša and Sorin
 proposed to add time zone arguments to other functions. These are all steps
 towards making the runtime's default time zone irrelevant. Your proposals
 need to be seen in this context, not just in the old ES5 context of a
 pervasively used implicit global time zone.



This is an improvement to be sure, but I don't think I understand how it
will have much impact on how pervasively the implicit global time zone is
dependent upon. The locale-dependent methods will still be just as
prominent and leaned on heavily I'd bet.

But I also don't see how the two approaches are in conflict at all -- to my
mind they complement each other nicely. Any `timeZone` properties in the
i18n formatting stuff would take precedence, of course, just as they do
today over the implicit global.


  Previously I'd suggested that Date instances should just own their
 timezone. Make explicit what's already there implicitly -- slap the system
 timezone as a symbol on Date.prototype and correct all locale-specific date
 methods to respect this symbol instead of some hidden global state. Of
 course this has no impact on a date's underlying value, just on the
 behavior of its locale methods.
 
  So which one are you proposing: having Date instances ... own their
 timezone or slap the system timezone as a symbol on Date.prototype and
 correct all locale-specific date methods to respect this symbol? These are
 not the same.
 
  As you've said, the underlying value of a date is UTC. But there are a
 bunch of locale-specific methods that depend on a global timezone state.
 I'm simply suggesting that instead of this global state it would be better
 if these locale-specific methods resolved the appropriate timezone instead
 by using an explicit property (using prototypal inheritance for a sane
 default). Again, this timezone is not part of the value of a date, and
 would not be preserved on copy. It simply codifies something that's already
 happening, allowing it to be controlled in an idiomatic way.

 Together with the sample code below, this sounds like a third variant:
 Date instances by default don't own their time zone, but the methods do a
 property lookup for the time zone on Date instances, which by default gets
 the property of Date.prototype, but can be overridden by adding

Re: a future caller alternative ?

[Dean Landolt]

On Mon, Mar 11, 2013 at 5:51 PM, Andrea Giammarchi 
andrea.giammar...@gmail.com wrote:

 the outer `with` statement ... you see my point? we are dropping powerful
 features in order to make JavaScript the toy we all think is since ever,
 isn't it  fear driven features, SES I've never personally used, things
 that any other general purpose language will leave/consider and then
 eventually tell developers how to or how to not use them as linter has done
 until now.


I can barely grok any of this but it smells unnecessarily trollish :-/


 Once JS will be not flexible, not dynamic, not powerful and with
 introspection possibilities, not JS anymore, I think we can also chose a
 new name for the language.


With all of the introspective goodness coming in es6 and es7 this statement
is ludicrous.


  Bear in mind, AFAIK I am the first one that suggested to freeze the
 global:
 http://webreflection.blogspot.de/2012/08/a-safer-js-environment.html

 and it was discussed here too but again, if I know what my code is doing,
 why you or your SES should be able to not let me do things the way I'd like
 to.

 As summary: the reason for dropping `caller` is privileged access but
 apply, bind, and call have same weakness/privilege/power ... why are these
 allowed?


This statement suggests you don't understand the arguments against caller.
It should be obvious that it's not the same thing as apply, bind, or call
-- in each of the latter forms you're explicitly handing out the `this`
reference capability. There's clearly no capability leak as with caller.


 Why cannot be `caller` back (humans can be wrong and hopefully fix,
 right?) and update specs so that Object.freeze(callback) or any other
 meaningful method will cause that behavior **when meant/needed** ?

 Minifiers, most of them, drop 'use strict' so 90% of code is still not
 strict in production so I believe is not too late.

 Best Regards



 On Mon, Mar 11, 2013 at 1:51 PM, Kevin Reid kpr...@google.com wrote:

 On Mon, Mar 11, 2013 at 12:56 PM, Brandon Benvie bben...@mozilla.comwrote:

  On 3/11/2013 12:41 PM, Kevin Reid wrote:

 Yes, taking care of all those things is necessary as well. ES5 provides
 us the tools to do so: Object.freeze(). If you recursively freeze all
 standard global objects then all of the issues you mention are handled.
 Secure ECMAScript (SES), developed by Mark Miller, does this; it provides
 an execution environment which _is_ secure (given a sufficiently conformant
 ES5 implementation).


 I would note, however, that it looks like at, least in browsers,
 freezing the window or even any single property on it will no longer be an
 option in the future. I believe the technique used by SES (correct me if
 I'm wrong) is using is more complex than simply freezing the window (though
 I believe it does freeze every property recursively from there).


 Right. We construct an object which has the bindings specified by ES5
 (Object, Array, parseInt, ...), but not the DOM (document, window,
 HTMLElement...). Actual access to the DOM by untrusted code is done with
 intermediation and is not part of SES per se. Trying to turn window itself
 into a sandbox is a non-starter.


 Something like shadowing all whitelisted global names and preventing any
 kind of direct access to the window object at all. This requires some
 amount of source code sandboxing to accomplish.


 The minimal solution is to (conservatively) find all (potential) free
 variables in the source code and bind them, which we currently do using an
 outer 'with' statement (in order to be able to intercept accesses using
 accessor properties, for best emulation of legacy global-variable
 semantics).


 ___
 es-discuss mailing list
 es-discuss@mozilla.org
 https://mail.mozilla.org/listinfo/es-discuss



 ___
 es-discuss mailing list
 es-discuss@mozilla.org
 https://mail.mozilla.org/listinfo/es-discuss


___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: a future caller alternative ?

[Dean Landolt]

On Mon, Mar 11, 2013 at 7:57 PM, Andrea Giammarchi 
andrea.giammar...@gmail.com wrote:

 On Mon, Mar 11, 2013 at 3:39 PM, Dean Landolt d...@deanlandolt.comwrote:

 it's not the same thing as apply, bind, or call -- in each of the latter
 forms you're explicitly handing out the `this` reference capability.
 There's clearly no capability leak as with caller.


 I wonder how would you access the `this` reference using `caller` from
 somewhere else, exactly, 'cause more I think about above sentence, the more
 I realize I really do not understand what are you talking about ...

 (function test() {
   function what() {
 alert(what.caller);
   }
   what();
 }());

 So I've got `test` there, now what about leaking `this` ... how ?


The leakage is that caller is a reference -- having that reference gives
you the *capability *to follow any further references on its object graph.
This reference wasn't explicitly handed out (as is always the case with
this-binding in call, apply and bind) -- it was just *leaked* out by the
simple fact that the function was called. It's very possible the caller has
all kinds of powers you didn't intend to expose to the callee -- these
powers have been leaked. It's really not complex -- this is an inherent,
unpluggable leak. And since OCap is now *the* security model of es, there
really no sense in trying to revive caller -- it's gone for good.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Internationalization: Support for IANA time zones

[Dean Landolt]

On Sat, Mar 2, 2013 at 5:11 AM, Mark Davis ☕ m...@macchiato.com wrote:

  It seems we have agreement that the canonicalized IANA names are not
 good for formatted strings. I like the CLDR solution, but see it as
 implementation dependent. *Maybe there's just no value in trying to
 define something in the standard since any implementer can claim that
 Center, North Dakota and GMT+09:00 are localized representations for
 some locale.* So, leave it all implementation dependent?

 ​I agree.​ (And you hit on an important point above.)



Maybe I'm missing something but ISTM there's an important difference
between Center, North Dakota and +09:00 -- DST.

I agree it doesn't make sense to solve this problem in the context of
formatting, but there wouldn't be an issue if we had a way to set the zone
of a Date. In another thread it was claimed that A Date is intended to
represent a specific instance in time, irrespective of time zone. But this
isn't true at all -- a Date already carries around a timezone tag
internally. And if you believe there's no use case for changing a date's
timezone, try partitioning a set of Dates by day (or week, month, year,
etc.) using a day boundary in a timezone other the current locale's or
Zulu. I've come up against this use case more than once, and The solution *
sucks*. It involves shipping some subset of the tz db to the client, which
is ridiculous -- especially because there's an easy fix...

A zone tag already exists, if implicitly, on Dates. What's the harm in
making it explicit -- exposing it as a unique symbol? It could be made
writable, and a registry of IANA timezones could be exposed as symbols. Per
the OP there we still need a mechanism to key the zone symbols -- I don't
understand this problem enough to say for sure but the mechanism Mark
described seems as good as any. As for how to query for a particular
exemplar city and what to do if not present -- this could be reduced to a
library problem.

This feature belongs in the language. It solves a real problem (as
evidenced by the libraries already built). But shipping all or part of the
Olsen db is madness -- the client already has it.



On Fri, Mar 1, 2013 at 10:33 PM, Norbert Lindenberg 
ecmascr...@lindenbergsoftware.com wrote:

 And the time zone names in formatted output when no localized time zone
 name is available:

 On Feb 28, 2013, at 15:35 , Norbert Lindenberg wrote:

  5) The set of combinations of time zone name and language tag for which
 localized time zone names are available is implementation dependent. Where
 no localized time zone name is available, the canonicalized name is used in
 formatted output.
 
  The last one I'm not entirely comfortable with: IANA time zone names can
 be long and unfamiliar (e.g., America/Indiana/Tell_City), and sometimes
 people think the wrong representative city was selected (e.g., Shanghai
 rather than Beijing for China). An alternative might be to prescribe
 formatting as an offset from UTC.


 On Feb 28, 2013, at 16:13 , Shawn Steele wrote:

  For #5 I might prefer falling back to English or something.  I don't
 think UTC offset is a good idea because that doesn't really represent a
 Timezone very well.  (If a meeting gets moved to a following week, that
 offset might change or be wrong)

 On Mar 1, 2013, at 7:40 , Mark Davis ☕ wrote:

  This is a problematic. The canonicalized names are very ugly. What we do
 in CLDR is return the last label, after some modifications (in
 http://www.unicode.org/repos/cldr/trunk/common/main/root.xml). We don't
 want to return the raw IDs. I think this needs to be implementation
 dependent.
 
  For example:
 
  zone type=Antarctica/DumontDUrville
  exemplarCityDumont d’Urville/exemplarCity
  /zone
  zone type=America/North_Dakota/Center
  exemplarCityCenter, North Dakota/exemplarCity
  /zone
 
  So I think we should just have #5 be:
 
  5) The set of combinations of time zone name and language tag for which
 localized time zone names are available is implementation dependent.

 On Mar 1, 2013, at 9:41 , Phillips, Addison wrote:

  I think the least surprise would result if the GMT+/- string were used
 when no local representation is available. While the actually time zone is
 more specific, most callers are just trying to put a date or time value
 into their output for human consumption. In most cases, the DST transition
 rules are unimportant to a specific date value being rendered and the GMT
 offset is at least somewhat compact. Users are probably more familiar with
 this presentation and certainly will be happier with it than
 America/Los_Angeles.

 It seems we have agreement that the canonicalized IANA names are not good
 for formatted strings. I like the CLDR solution, but see it as
 implementation dependent. Maybe there's just no value in trying to define
 something in the standard since any implementer can claim that Center,
 North Dakota and GMT+09:00 are localized representations for some
 locale. So, leave it all implementation 

Re: Check out Dart's iterators

[Dean Landolt]

Has the iteration protocol been given a close look since unique symbols hit
the scene? I know the iterator key was changed to a symbol (which makes
great sense) but ISTM symbols offer up some design flexibility that, as far
as I know, just isn't possible in any of the other languages mentioned WRT
prior art.

For example, the first argument to the iterator function could be a symbol
that acts as a StopIteration semaphore for that iteration run. Obviously
consuming an iterator with `for of` or comprehensions would implement the
protocol for you (generating the symbol and testing it's identity under the
covers), but it'd still be just as easy (perhaps more so) to run off an
iterator run manually. If you happen know the full alphabet of the sequence
you're iterator over you don't even have to use a symbol. I think it's safe
to say very few sequences won't have holes, so providing nothing at all
would do the Right Thing in the vast majority of cases.

I know it's too late in the game for new features. Though, this is really a
small tweak to the current proposal -- it's essentially the same protocol
with a different signaling mechanism. There sure seem to be an awful lot of
pros. It's easier to get right than the throw StopIteration dance, and I
couldn't imagine a way it could be less efficient. AFAICT it's not subject
to the deficiencies I've seen raised about the current spec -- no
instanceof StopIteration confusion and no unnecessary catch blocks, for
instance. I'm not aware of any cons.


On Sun, Feb 10, 2013 at 9:35 PM, Claude Pache claude.pa...@gmail.comwrote:


 Le 10 févr. 2013 à 22:01, David Bruant bruan...@gmail.com a écrit :

  snip
 
  I have to note that there is a minor security hazard in code using
 iterators naively:
 import process from m;
 
 var a = [1, 2, 3, 4, 5];
 var next = 0;
 var it = {
 next: function(){
 if(next  a.length){
 // If the call to process throws StopIteration because
 it's malicious/buggy,
 // so does this code and that's largely unexpected.
 return process(a[next++]);
 }
 else{
 throw StopIteration;
 }
 }
 }
 
  You can always protect yourself by wrapping the call to process with a
 try/catch block.
  snip


 Note that the same issue arises with generators:

 function* gen(a) {
 var next = 0;
 if (next  a.length) {
 // the iterator will end prematurely if process
 throws a StopIteration
 yield process(a[next++]);
 }
 }

 In order to mitigate the problem, instead of throwing a generic
 StopIteration, I think we ought to throw a specific StopIteration instance
 with information on which iterator has thrown. More precisely, inside a
 generator function, a return statement will throw a StopIteration instance
 with its source property set to the generator iterator which was
 terminated.

 For manually throwing a StopIteration from inside a next method of an
 iterator, we could use:

 throw new StopIteration(this)

 And instead of e instanceof StopIteration, we may use a more precise
 check:

 e instanceof StopIteration  e.source === it


 —Claude
 ___
 es-discuss mailing list
 es-discuss@mozilla.org
 https://mail.mozilla.org/listinfo/es-discuss

___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Ducks, Rabbits, and Privacy

[Dean Landolt]

On Tue, Jan 22, 2013 at 11:13 AM, Brandon Benvie
bran...@brandonbenvie.comwrote:

 I also agree with everything that Nathan said.

 To clarify, there's Symbols and then there's private Symbols. I don't
 think anyone in TC39 is suggesting the removal of Symbols in general.
 Private Symbols have a much more specific set of uses cases than do just
 Symbols in general, and regular Symbols will accomplish the goal of
 encapsulation.


No, symbols accomplish the goal of stratification [1] (I've used this
terminology in the past and was corrected but from a mathematical logic
standpoint this property is precisely what symbols give us). Unique symbols
fail as a means of encapsulation -- and this is whole point of private
symbols.


  Regular symbols are only enumerated by a new ES6 function and are unique.
 Currently, the only difference between a normal symbol and a private Symbol
 is that private symbols are not enumerated by getOwnKeys and they are
 slated to eventually be awkward to use with proxies. Otherwise a normal
 (aka Unique) Symbol works exactly the same.


You're awkwardly (and derisively) describing what could more concisely be
called encapsulation. This is the difference between unique and private
symbols, as Nathan expressed beautifully.

[1] http://en.wikipedia.org/wiki/Stratification_%28mathematics%29
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Ducks, Rabbits, and Privacy

[Dean Landolt]

On Tue, Jan 22, 2013 at 4:03 PM, Kevin Smith khs4...@gmail.com wrote:



 +1 to this and everything else Nathan has said. Watching all this intense
 back and forth, there are a lot of good points, some of which almost
 convince me that weak maps are sufficient and private symbols are
 unnecessary. But when I step back for even a minute, as a developer private
 symbols are exactly what I want, and weak maps are an un-ergonomic hack.


 Are you sure they are what you want?  When you attempt to create private
 methods using private symbols, you will break the inheritance mixin
 pattern.  Is that what we want?


The idea of a WeakMap desugaring appeals to me, though I don't understand
how this desugaring solves the mixin inheritance problem? I'm probably
missing something -- I can't tell how prototypal inheritance is intended to
work, if at all, with private properties. Would it disappear? If so, this
would break a core tenet of the object model, which seems more detrimental
than breaking a very specific pattern (a diamond-shaped antipattern?) in
one specific case. Naive mixins are naive -- this seems like an acceptable
trade-off, especially when there are patterns with more integrity available.


 A weakmap-based solution can be made as ergonomic as you like.  Without
 syntax, it can be a simple function call (like Juan Dopazo's), and with
 syntax...


If a desugaring could be made to support prototypal inheritance this would
be ideal. But assuming private symbols cannot be intercepted by proxies
would there be an observable difference between private symbols and this
kind of weakmap desugaring (including some kind of gc hint, per the gist)?
If none, and Allen finds private symbols helpful for specification
purposes, is it worth bothering with a desugaring at all (including
whatever it entails, like WeakMap gc hints and any other baggage)?
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: (Map|Set|WeakMap)#set() returns `this` ?

[Dean Landolt]

On Thu, Dec 6, 2012 at 2:41 PM, Jussi Kalliokoski 
jussi.kallioko...@gmail.com wrote:

 On Thu, Dec 6, 2012 at 8:44 PM, Rick Waldron waldron.r...@gmail.comwrote:

 values() returns an iterable of the values in the array. Array, Map and
 Set will receive all three: keys(), values(), entries(). Feel free to start
 a new thread if you want to argue about iterator protocol.


 Yes, I apologized for that mistake already, I remembered incorrectly. I
 don't have a want to argue, just like I'm sure you don't.



All this misses your important pears and oranges point. These are not
mutable APIs, which is a key distinction. The sort method would have been a
good example of a mutable API returning `this`. But it's not exactly a
model to emulate.



  I'm absolutely not dodging the question, I answered this in a previous
 message, much earlier. Cascade/monocle/mustache is not a replacement here.


 That wasn't the question I asked. Cascade/monocle/mustache aren't even
 ready yet, and are hence in no way an indication that chaining cannot be
 made a language-side construct. I believe it can and will, and at that
 point, returning this becomes completely meaningless. But (I don't see) how
 can you fix this on the language syntax side:

 var obj = {
   foo: bar,
   baz: taz
 }
 set.add(obj)
 return set

 instead of simply:

 return set.add({
   foo: bar,
   baz: taz
 })


 What I mean is that the not all functions in an API can return `this`
 anyway (like getters), so it's inconsistent. After all, it's not a very
 useful API if you can just set but not get.


 That's exactly my point. The set/add API return this, allowing
 post-mutation operations to be called: such as get or any of the examples
 I've given throughout this thread.


 What? I'm really sorry, but I can't understand how what I said leads to
 your point. But I bet we're both wasting our time with this part, so it's
 probably best to just leave it.


 No one said anything about applying return this to everything that's not
 a getter. That was exactly what the criteria we have consensus on defines.
 It's in the meeting notes for Nov. 29.


 Sorry, about that, the meeting notes (in the part Cascading this
 returns) just say:

 Supporting agreement
 (Discussion to determine a criteria for making this API specification
 distinction)
 Consensus... with the criteria that these methods are not simply a set of
 uncoordinated side effects that happen to have a receiver in common, but a
 set of coordinated side effects on a specific receiver and providing access
 to the target object post-mutation.

 With no reference to the logic behind the conclusion (these methods are
 not simply a set of uncoordinated side effects that happen to have a
 receiver in common). I fail to see how .set()/.add() are a special case.
 Am I missing something?

  Please read everything I've written so far, it's not fair to make me
 constantly repeat myself in this thread.


 I agree, and I'm sorry, but I have, at least everything on this thread,
 those referred to and those that have seemed related. I'm doing my best,
 but I'm afraid I can't keep up with every thread in my inbox, and I don't
 think it's a good reason for me not to contribute at all.

 Of course I could've shown it as you have here, but I made examples where
 the intention was to match the preceding examples illustrated in the gist.


 Fair enough, but I fail to see the convenience in your examples.

   Why would you need to stuff everything in one line?


 As evidenced several times throughout this thread, the pattern is widely
 implemented in the most commonly used library APIs, so I guess the answer
 is The kids love it.



But which kids? There certainly appears to be quite a sampling bias in your
survey -- I didn't see a single actual *collection* library. Sampling their
choices would be the most helpful, not *what the kids are doing*.

Plus there are other alternatives I haven't seen discussed, so the design
space has barely been explored. For instance buckets [1] is a nice example
of a collection library that takes an approach more reminiscent of
javascript's existing array mutation methods -- its add method returns
`true` if the item was newly created or `false` if it was already present
in the collection -- a lot like javascript's delete operator. I'm not
necessarily advocating for this, just offering up the idea that any survey
should look closer at existing collection libraries to get a better feel
for the full design space.

[1] https://github.com/mauriciosantos/buckets



 document.write() is widely implemented too, doesn't make it good or worth
 repeating.



That's a low blow :)



  This way it's more version control friendly as well, since those two
 lines of code have actually nothing to do with each other, aside from
 sharing dealing with the same object. Why do you want to get all of those
 things from .set()/.add(), methods which have nothing to do with what
 you're getting at?


 You could just as easily 

Re: Symbols, Protocols, Frames, and Versioning

[Dean Landolt]

On Fri, Oct 5, 2012 at 8:45 AM, Andreas Rossberg rossb...@google.comwrote:

 On 5 October 2012 14:26, Sam Tobin-Hochstadt sa...@ccs.neu.edu wrote:
  On Fri, Oct 5, 2012 at 8:21 AM, Kevin Smith khs4...@gmail.com wrote:
 
  Sounds good.  As an aside, does the symbol in this case provide any
 function
  other than wrapping the string itself?  Does the symbol carry any
  information that the string does not, from the point of view of the
 script?
 
  No, in this case the results of `Symbol.for` are just a duplicate of
  the space of strings (just the way interned symbols are in Lisp).

 Indeed, which is why I'm not sure I understand what this idea is
 trying to achieve. Is it more than just an ad hoc way to introduce a
 second namespace?



Symbols already introduce a second namespace, and in a way that allows us
represent infinitely many ad hoc string namespaces side-by-side, with no
need for nesting (which means the cardinality of symbols  strings I
guess). But Symbol.for wouldn't be an ad hoc namespace -- IIUC it would be *
the* de jure namespace to map string names to references for system-wide
concepts like the iterator symbol.

IMHO the module namespace is a very similar to the module namespace,
perhaps too similar to justify Symbol.for. Wouldn't it be easier to spec.
some subset of the module namespace to behave in the manner described for
Symbol.for? In fact this is exactly how I imagined the @ module prefix
(often used by Brendan in module examples) would work.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Symbols, Protocols, Frames, and Versioning

[Dean Landolt]

On Fri, Oct 5, 2012 at 9:51 AM, Dean Landolt d...@deanlandolt.com wrote:



 On Fri, Oct 5, 2012 at 8:45 AM, Andreas Rossberg rossb...@google.comwrote:

 On 5 October 2012 14:26, Sam Tobin-Hochstadt sa...@ccs.neu.edu wrote:
  On Fri, Oct 5, 2012 at 8:21 AM, Kevin Smith khs4...@gmail.com wrote:
 
  Sounds good.  As an aside, does the symbol in this case provide any
 function
  other than wrapping the string itself?  Does the symbol carry any
  information that the string does not, from the point of view of the
 script?
 
  No, in this case the results of `Symbol.for` are just a duplicate of
  the space of strings (just the way interned symbols are in Lisp).

 Indeed, which is why I'm not sure I understand what this idea is
 trying to achieve. Is it more than just an ad hoc way to introduce a
 second namespace?




I really need learn to proofread better! Corrected below...

Symbols already introduce a second namespace, and in a way that allows us
 represent infinitely many ad hoc string namespaces side-by-side, with no
 need for nesting (which means the cardinality of symbols  strings I
 guess). But Symbol.for wouldn't be an ad hoc namespace -- IIUC it would be
 *the* de jure namespace to map string names to references for system-wide
 concepts like the iterator symbol.

 IMHO the *Symbol.for* namespace is very similar to the module namespace,
 perhaps too similar to justify Symbol.for. Wouldn't it be easier to spec.
 some subset of the module namespace to behave in the manner described for
 Symbol.for? In fact this is exactly how I imagined the @ module prefix
 (often used by Brendan in module examples) would work.

___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Symbols, Protocols, Frames, and Versioning

[Dean Landolt]

On Thu, Oct 4, 2012 at 2:29 PM, Brendan Eich bren...@mozilla.com wrote:

 Tab Atkins Jr. wrote:

 It might be useful to expose this functionality with a more obvious
 name, to underscore that you lose the secrecy/unforgability.
 Symbol.public()?


 We are mooting public as the keyword for non-private but unique symbols,
 so that's ambiguous. ReallyPublic? :-P We want to capture the singleton
 sharing, and 'intern' is the jargon word to use. For the jargon-disabled,
 I'm not sure what to use, but perhaps teaching people about intern'ing is
 better than using some long Java-esque name.



Maybe Symbol.namespace('iterator') to communicate that you're referencing
the global System namespace pool. Anyone can easily roll their own
namespace pools too.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Symbols, Protocols, Frames, and Versioning

[Dean Landolt]

On Thu, Oct 4, 2012 at 2:51 PM, Brendan Eich bren...@mozilla.com wrote:

 Dean Landolt wrote:

  On Thu, Oct 4, 2012 at 2:29 PM, Brendan Eich bren...@mozilla.commailto:
 bren...@mozilla.com wrote:

 Tab Atkins Jr. wrote:

 It might be useful to expose this functionality with a more
 obvious
 name, to underscore that you lose the secrecy/unforgability.
 Symbol.public()?


 We are mooting public as the keyword for non-private but unique
 symbols, so that's ambiguous. ReallyPublic? :-P We want to capture
 the singleton sharing, and 'intern' is the jargon word to use. For
 the jargon-disabled, I'm not sure what to use, but perhaps
 teaching people about intern'ing is better than using some long
 Java-esque name.



 Maybe Symbol.namespace('iterator') to communicate that you're referencing
 the global System namespace pool. Anyone can easily roll their own
 namespace pools too.


 Urgh, namespace is misleading, it suggests Common Lisp's symbol packages,
 the AS3/ES4 namespaces, XML namespaces. Here, @iterator is not a prefix or
 part of a pair, or set-of-symbols. It's just a symbol you can find from a
 string.



I admit the historical baggage may be too much to shake but what we're
talking about here is quite precisely a namespace :)
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Symbols, Protocols, Frames, and Versioning

[Dean Landolt]

On Thu, Oct 4, 2012 at 3:24 PM, Brendan Eich bren...@mozilla.com wrote:

 Dean Landolt wrote:

  On Thu, Oct 4, 2012 at 2:51 PM, Brendan Eich bren...@mozilla.commailto:
 bren...@mozilla.com wrote:

 Urgh, namespace is misleading, it suggests Common Lisp's symbol
 packages, the AS3/ES4 namespaces, XML namespaces. Here, @iterator
 is not a prefix or part of a pair, or set-of-symbols. It's just a
 symbol you can find from a string.



 I admit the historical baggage may be too much to shake but what we're
 talking about here is quite precisely a namespace :)


 I don't think so, but definitions vary. Could you cite a source for yours?


I just meant in the literal sense: a namespace is just a string key
space. Using symbols as interned strings allows you to add any number of
namespaces to an object, including some language-defined system
namespace. And this is what we're after, isn't it?
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Suggestions for Set

[Dean Landolt]

On Wed, Oct 3, 2012 at 3:47 AM, Jussi Kalliokoski 
jussi.kallioko...@gmail.com wrote:

 On Wed, Oct 3, 2012 at 10:24 AM, Andreas Rossberg rossb...@google.comwrote:

 On 3 October 2012 05:38, Brendan Eich bren...@mozilla.com wrote:
  Which is more important, iterating over holes (preserved if possible),
 or
  skipping them and therefore spreading array-likes but not iterables?

 I, for one, couldn't care less about holes. We shouldn't compromise
 any useful feature just for the sake of preserving some array hole
 craziness.


 I agree. Unless there's a sane use case for holes with the spread
 operator, I don't think it makes sense to make compromises because of them,
 especially since we aren't breaking backwards compatibility or anything. We
 can actually make something better here.



I seem to remember an issue re: what to do with infinite iterators
(generators)? If that's correct, was there an agreed-upon resolution?
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Sets plus JSON

[Dean Landolt]

On Wed, Oct 3, 2012 at 2:19 PM, Rick Waldron waldron.r...@gmail.com wrote:



 On Wed, Oct 3, 2012 at 2:04 PM, Rick Waldron waldron.r...@gmail.comwrote:



 On Wed, Oct 3, 2012 at 1:43 PM, Brandon Benvie bran...@brandonbenvie.com
  wrote:

 Another options for Maps is to represent them as an array of [key,
 value].


 Which is a rough approximation of what a Map looks like internally.



 Sorry, this is incorrect. Map looks more like:

 [key1, key2]
 [value1, value2]

 Sorry for confusion


I image it looking something like [key1, value1, key2, value2...] -- index
% 2 implies values. Anything more would mean an awful lot of unnecessary
allocations. I don't see why this wouldn't be sufficient for the json form
as well, especially if the language had something like a take2 iterator.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Symbols, Protocols, Frames, and Versioning

[Dean Landolt]

On Wed, Oct 3, 2012 at 5:09 PM, Brendan Eich bren...@mozilla.org wrote:

 Domenic Denicola wrote:

 Would it suffice to allow cross-frame sharing of symbols via postMessage
 and its structured clone algorithm? They're immutable, right?


 They are immutable but you'd still have to pass your @iterator to another
 same-origin frame, and then have to use it carefully when iterating objects
 from the first frame. This is unusable.

 Making @iterator a singleton (to the limits of observability: same-origin,
 CORS, out-of-process-via-DOM window.open in IE9+ notwithstanding!) can be
 done. That wins, no need to pass and use the other frame's @iterator symbol.

 But how to let users create such singletons?


The module system does this for us, doesn't it? I can't really see the
problem -- anywhere you can share objects with private symbols you can
always provide the symbols themselves. Module sandboxes will come in handy.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: typeof symbol (Was: Sept 19 TC39 Meeting Notes)

[Dean Landolt]

On Mon, Oct 1, 2012 at 12:00 PM, Rick Waldron waldron.r...@gmail.comwrote:



 On Mon, Oct 1, 2012 at 5:26 AM, Andreas Rossberg rossb...@google.comwrote:

 On 30 September 2012 00:08, Brendan Eich bren...@mozilla.org wrote:
  I think this is too philosophical a discussion to result in a strong
 reason
  to risk symbol. Just my gut-check. Other TC39ers should weigh in
 (Andreas
  R. especially).

 Type symbol would be my preference, but it is difficult to estimate
 (for me) whether that involves a risk.

 However, this clearly is an issue beyond symbols alone. The same
 problem re-arises whenever we have to add new primitive types in the
 future. It doesn't seem like a sustainable strategy to fake any new
 type ever into an object. Perhaps it is less harmful on the long run
 if we took the chance to clarify _now_ that the set of strings
 returned by 'typeof' is not fixed, and should not be treated as such?


 +1 for symbol, after reading through past concerns about adding new
 entries to typeof operator results, I'm not convinced that adding something
 completely new would have any negative side-effects. I'll be the first to
 admit that there are probably edge cases that I may have missed or didn't
 find, but I think the real risk is in piling new things on to existing
 typeof results when they questionably don't belong.


To try and make clear the risk that Brendan's alluding to think of it this
way: how many times have you written code that type-checks and assumes the
range of typeof is fixed? I've written code like this more times than I can
count:

if (attr == null) // null or undefined
else if (typeof attr == 'string') // string
else if (typeof attr == 'number') // number
else if (typeof attr == 'object') // whoops...
// handle arrays, objects, dates, regex, etc.

For code that falls through to 'object' it's possible the handler is
sufficiently generic, but changing the range of typeof changes assumptions
and *will* silently break old code, and for the same reason typeof 'null'
was nixed. This is a subtly backward-hostile change that doesn't fix
anything. It just introduces another barrier to es-next migration.

I'm convinced that typeof is a lost cause, but FWIW I believe symbols
themselves give us a way out of this mess.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss