Re: Could delete methods rename to remove?
On Wed, Dec 18, 2013 at 1:55 PM, Rick Waldron waldron.r...@gmail.comwrote: Submit patches—libraries intended for use in IE8 should be made to support that platform, it's that simple. Submitting patches is irrelevant and impractical here. Why use es5-shim? Because we want to use some scripts written in es5 WITHOUT asking the authors change their code. Though sometimes es5-shim is not enough (for those rely on getter/setter syntax or Object.create(null) which hard to shim). What I'm talking about is: there will be many modules using ES6 API but still can be used in ES5 or pre-ES5 or even pre-ES3 environment with es5/es6 shims (if they do not rely on the complex features like Proxy or Generator). So bordering the original authors to change their code from a.delete() to a['delete'] are meaningless and I don't expect they will accept such patch. (Do anyone really think change a.delete to a['delete'] is a patch?) Wrong—that impairment has nothing to do with browsers, but with _existing_ code that makes incorrect assumptions (or none at all) about the return value of typeof. I don't see any difference here. Whether it's correct or incorrect assumption, the spec can not change that behavior. In my opinion, using reserved words as methods name in standard library is far more problematic than the case of typeof null (because I don't know any real product code rely on typeof null === 'object' and if any it's very easy to fix). ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: About Array.of()
This is an old thread which I like to mention again. The proposal is change the method name from Array.of() to Array.fromElements() to make it clear especially for non-English native programmers. It seems the thread is totally ignored... On Tue, Aug 28, 2012 at 5:56 PM, Jussi Kalliokoski jussi.kallioko...@gmail.com wrote: On Tue, Aug 28, 2012 at 12:40 PM, Axel Rauschmayer a...@rauschma.dewrote: However, I'm still not quite sure what the use case is for this. For code generation, if you know how many elements there are and what they are enough to put them in the Array.of(...,...,...) call, why not just use [...,...,...]? Unless it's supposed to be used for converting array-likes to arrays, where I really don't think this is the best function signature. For the dart example, why not just use [] and you avoid the gotcha? map and map-like scenarios are another use case: [1,2,3].map(Array.of) // [[1], [2], [3]] But, as Domenic mentions, it does indeed compete with: [1,2,3].map(...x = [...x]) Yeah, and in that case (making every element of an array an array), actually: [1,2,3].map(x = [x]) Which is even shorter. I really have a hard time seeing any value in having this feature. All the problems it's supposed to solve (at least the ones presented here) already have better solutions. :D Cheers, Jussi ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Could delete methods rename to remove?
Le 17/12/2013 22:52, Alex Kocharin a écrit : I believe ecmascript isn't versionless yet like html is, and that number means something. As far as I'm concerned, ECMAScript is versionless. As versionless as HTML. Implementation aren't monolithically moving from one standard version to the other. I don't believe we've ever seen a browser with exactly ES3 or exactly ES5 (wait... maybe IE10?! but with IE11, they're back to ES5+some ES6 features) Modulo spec bugs and history details, version n is fully backward-compatible with version n-1. TC39 decided to move to a more iterative spec release schedule recently too. The version has also never been exposed to the runtime which encourages people to do version-agnostic feature detection. Version numbers mean nothing. Version numbers are kept only for the same reason W3C produces HTML5 and 5.1 and 6 spec. And I think the reason is that most people aren't used to how the web works and are reassured with classic versioning systems... so reassured some people pay a different price to the same company when they're sold a HTML4 site or an HTML5 site (because 5 4, you know...). True story. Maybe versions is just better marketing because in the next version suggests a stronger progress than in the next iteration? David ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: About Array.of()
From: Shijun He hax@gmail.com Subject: Re: About Array.of() This is an old thread which I like to mention again. The proposal is change the method name from Array.of() to Array.fromElements() to make it clear especially for non-English native programmers. `Array.of` sounds a lot more expressive than `.fromElements` to me. Optimally I'd like the array constructor to just accept a collection and convert it to an array but that's not going to happen. Would you mind explaining the issue here for non native English speakers? ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
`String.prototype.contains(regex)`
Both `String.prototype.startsWith` and `String.prototype.endsWith` throw a `TypeError` if the first argument is a RegExp: Throwing an exception if the first argument is a RegExp is specified in order to allow future editions to define extends that allow such argument values. However, this is not the case for `String.prototype.contains`, even though it’s a very similar method. As per the latest ES6 draft, `String.prototype.contains(regex)` behaves like `String.prototype.contains(String(regex))`. This seems inconsistent. What’s the reason for this inconsistency? ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: `String.prototype.contains(regex)`
On Dec 18, 2013 3:31 PM, Mathias Bynens math...@qiwi.be wrote: Both `String.prototype.startsWith` and `String.prototype.endsWith` throw a `TypeError` if the first argument is a RegExp: Throwing an exception if the first argument is a RegExp is specified in order to allow future editions to define extends that allow such argument values. However, this is not the case for `String.prototype.contains`, even though it’s a very similar method. As per the latest ES6 draft, `String.prototype.contains(regex)` behaves like `String.prototype.contains(String(regex))`. This seems inconsistent. What’s the reason for this inconsistency? Not sure why the inconsistency, but afaik with for example WebIDL if you say something accepts a string, it accepts pretty much anything that can be coerced to a string, so the case of `contains` may come from there. ___ 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.assign with several source objects
Are we really doing Object.assign for ES6? We postponed Object.mixin so we
should probably postpone Object.assign too.
On Wed, Dec 18, 2013 at 4:23 AM, A Matías Quezada amati...@gmail.comwrote:
I can't see a better use for extra arguments than multiple extensions.
This is how current libraries implement it and we expect to replace it with
Object.assign. In case Object.assign accepts only two arguments I think
this snippet will be everywhere
Object.assign(Object.assign({}, defaultParams), userParams);
// or
[ {}, defaultParams, userParams ].reduce(Object.assign);
I think using properties descriptor at Object.assign will be a mix of
concepts, and a pattern I see a lot less than _.extend, and we'll be able
to do it anyway
Object.defineProperties(Object.assign({}, properties), descriptors);
// or
Object.assign(Object.create(something, descriptors), properties);
And deep copy doesn't look like an option for me, as Brendan said it adds
so much complexity for an edge case.
I think accepting several source objects like _.extend, $.extend and
angular.extend would be the more practical option.
---
A. Matías Quezada
Senior Javascript Developer
amati...@gmail.com
2013/12/18 Andrea Giammarchi andrea.giammar...@gmail.com
Rick I tend to aree with you if not that the second argument of
Object.create has basically reached zero libraries and popularity out there
due un-shimmable and boring to write common/usual properties.
In this very specific case it would be inconsistent with the previous
argument too since that won't be checked through getOwnPropertyNames in any
case ... you know what I mean?
Cheers
On Tue, Dec 17, 2013 at 7:06 PM, Rick Waldron waldron.r...@gmail.comwrote:
On Tue, Dec 17, 2013 at 8:17 PM, Brendan Eich bren...@mozilla.comwrote:
It's now or never. I agree multiple sources are useful enough to do
now; I don't see a different third parameter that would be precluded by
deciding this. But others may disagree.
A third Properties argument that matches the second Properties argument
to Object.create() and Object.defineProperties
class Cycle {
constructor(details) {
Object.assign(this, details, {
wheels: {
value: details.type === tricycle ? 3 : 2,
configurable: false,
writable: false
}
});
}
}
var trike = new Cycle({
color: red,
type: tricycle
});
... Which doesn't break the reduce pattern since the index would
effectively be meaningless in that context, ie.
Object.getOwnPropertyNames(Object(1)).length === 0;
Anyway...I had originally pushed for Object.assign with multiple sources
and dropped it when consensus seemed to hinge on one target, one source.
The third Properties argument is compelling and doesn't prevent using
Object.assign as a primitive mechanism for library code to build on top of.
Rick
___
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
--
erik
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Object.assign with several source objects
On Wed, Dec 18, 2013 at 10:35 AM, Erik Arvidsson erik.arvids...@gmail.comwrote: Are we really doing Object.assign for ES6? We postponed Object.mixin so we should probably postpone Object.assign too. Yes, this was originally accepted on it's own merit, before Object.define/mixin. Object.assign is already widely implemented in many forms (under different names) https://gist.github.com/rwaldron/3744794 Rick ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: `String.prototype.contains(regex)`
+1 to what Benjamin says On Wed, Dec 18, 2013 at 9:16 AM, Benjamin (Inglor) Gruenbaum ing...@gmail.com wrote: -- Forwarded message -- From: Mathias Bynens math...@qiwi.be However, this is not the case for `String.prototype.contains`, even though it’s a very similar method. As per the latest ES6 draft, `String.prototype.contains(regex)` behaves like `String.prototype.contains(String(regex))`. This seems inconsistent. What’s the reason for this inconsistency? May I ask what String.prototype.contains accomplish with a regular expression (that we don't already have with `RegExp.test`)? I keep writing `.indexOf(..) !== -1)` or shimming contains because that's a problem and contains solves it. I risk being very short sighted here but how could you possible extend contains for anything but a string? I think that there is no reason to throw rather than allow things that _behave_ like a string in if we don't see any potential for extension. Benjamin ___ 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: About Array.of()
Array.of sounds expressive only for native speakers. English is not my first language and it sounded expressive to me. I've asked 5 random friends that code and they all said it sounded fine to them. While that's not real evidence, it still shows that the only doesn't hold here. The only valid use case of Array.of is high-order function. No it's not. The main use case I see is converting array like structures (like NodeLists) to arrays without having to do that dirty `Array.prototype.splice.call` call: Array.of(document.querySelectorAll(.bar)) Higher order functions are a real use case but for sure not the only one. I completely agree with Rick that fromElements is confusing for the API __especially__ that creating an array out of actual DOM Elements _is_ a use case and it implies that it only works for _that_ use case. Like I said, the _optimal_ thing would have been to be able to do `Array(arrayLike)` and have it just work and create a new array from that collection (like collections tend to do in Java, C#, Python etc) but it's too late for that. That breaks ES (Array([1]) returns [[1]]). Array.of seems very close of that, you make an array of the items passed. The fact it's a static method makes it very clear that that's what it does IMO (although personally I'd favor putting it somewhere else). On Wed, Dec 18, 2013 at 9:01 PM, Shijun He hax@gmail.com wrote: On Thu, Dec 19, 2013 at 12:08 AM, Rick Waldron waldron.r...@gmail.comwrote: `Array.of` sounds a lot more expressive than `.fromElements` to me. Agreed. 1) Array.of sounds expressive only for native speakers. Non native programmers will have no idea about Array.of method, because they never seen such named method with such usage in any codes of any programming languages before (at least I never seen), if you search `array.of` in github, you will see many `array of int` `array of byte` `array of strings` `array of Book` or `array of Point`... in code or comments. 2) In fact such expressive is MEANINGLESS because we will never write `var a = Array.of(1, 2, 3)` instead of `var a = [1, 2, 3]` The only valid use case of Array.of is high-order function. So what's the readability of `foo(bar, array.of)` ? I just find that Dave Herman already pointed out this problem in the original thread: That said, the readability story you and I tweeted about is not so compelling given that, in the first-order usage pattern an array-literal is strictly more readable. So a longer name like Array.fromElements or something might be okay. Interesting that Dave (native speaker) and 程劭非(a non native speaker which suggest this name in this thread) both choose fromElements in the first place. Additionally, `fromElements` will also be confusing when the new DOM `Elements` API arrives: http://dom.spec.whatwg.org/#elements Well, even it's confusing it's still better than `of` for the use case, and some other alternatives: Array.fromItems // fromXXX has another benifit that alternative constructors (String.fromCharCode, Array.from) all begin with `from` Array.fromList Array.fromArguments Array.newArray Array.makeArray Array.theFixedConstructorWithoutGotchas I like the last one ;) what about you? Optimally I'd like the array constructor to just accept a collection and convert it to an array but that's not going to happen. Would you mind explaining the issue here for non native English speakers? The specification reads: Array.of(...items) Which, when said out loud is: Array of items Even `Array.ofItems` is better than `Array.of` for the only use case: foo(bar, Array.ofItems) I don't know how much clearer that can get. Bikeshedding the name of an API at this stage in ES6's progress is not a valuable use of anyone's time. Come on, there are only two things in Computer Science: cache invalidation and naming things. And if we don't fix bad names in this stage, we will lose the chance for ever. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: About Array.of()
On Dec 18, 2013, at 11:01 AM, Shijun He wrote:
...
2)
In fact such expressive is MEANINGLESS because we will never write `var a =
Array.of(1, 2, 3)` instead of `var a = [1, 2, 3]`
Note that 'of' works to create instances of subclasses or Array (and typed
arrays) while array literals do not.
class MyArray extends Array { }
var ma = MyArray.of(1,2,3);
console.log(ma instanceof MyArray); //true
allen
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: About Array.of()
On Thu, Dec 19, 2013 at 4:04 AM, Benjamin (Inglor) Gruenbaum
ing...@gmail.com wrote:
Array.of sounds expressive only for native speakers.
English is not my first language and it sounded expressive to me. I've
asked 5 random friends that code and they all said it sounded fine to them.
While that's not real evidence, it still shows that the only doesn't hold
here.
Could you ask what's your and your friend's native language?
The only valid use case of Array.of is high-order function.
No it's not. The main use case I see is converting array like structures
(like NodeLists) to arrays without having to do that dirty
`Array.prototype.splice.call` call:
Array.of(document.querySelectorAll(.bar))
Oops, it should be Array.from(document.querySelectorAll('.bar')).
Higher order functions are a real use case but for sure not the only one.
I completely agree with Rick that fromElements is confusing for the API
__especially__ that creating an array out of actual DOM Elements _is_ a use
case and it implies that it only works for _that_ use case.
I already give some alternatives. Just choose what you like.
Like I said, the _optimal_ thing would have been to be able to do
`Array(arrayLike)` and have it just work and create a new array from that
collection (like collections tend to do in Java, C#, Python etc) but it's
too late for that. That breaks ES (Array([1]) returns [[1]]). Array.of
seems very close of that, you make an array of the items passed. The fact
it's a static method makes it very clear that that's what it does IMO
(although personally I'd favor putting it somewhere else).
So could I use your misunderstanding of Array.of/from as a example that
Array.of is a bad name? :)
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: About Array.of()
On Thu, Dec 19, 2013 at 4:37 AM, Allen Wirfs-Brock al...@wirfs-brock.comwrote:
On Dec 18, 2013, at 11:01 AM, Shijun He wrote:
...
2)
In fact such expressive is MEANINGLESS because we will never write `var
a = Array.of(1, 2, 3)` instead of `var a = [1, 2, 3]`
Note that 'of' works to create instances of subclasses or Array (and
typed arrays) while array literals do not.
class MyArray extends Array { }
var ma = MyArray.of(1,2,3);
console.log(ma instanceof MyArray); //true
allen
var ma = new MyArray(1, 2, 3)still work.
If we want to avoid the constructor, we can :
var ma = MyArray.from([1, 2, 3])
or just fix the constructor --- if the behavior of default constructor is
confusing why not fix it? For the built-in Array we can not, but you
already extend it here!
class MyArray extends Array {
constructor(...a) { this.push(...a) }
}
So I still think only high-order usage for built-in Array is a real use
case.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: `String.prototype.contains(regex)`
then none of them should throw, imho startsWith is like dropping the `/^` form a `RegExp`, endsWith like dropping the `$/` part .. that's it The problem with RegExp is usually the safe escaping, having 1 char less to type for a `.test()` - so actually counting chars in the method name is even more - is not a win In `/^th(is|at)$/.test(str)` the useful `RegExp` part is in the middle so what was the reason to not coerce to string as basically every other `String.prototype` method does already if consistency was actually the reason ? Is it because split accepts `RegExp` too ? 'cause that's completely different scenario. On Wed, Dec 18, 2013 at 1:01 PM, Jason Orendorff jason.orendo...@gmail.comwrote: On Wed, Dec 18, 2013 at 11:16 AM, Benjamin (Inglor) Gruenbaum ing...@gmail.com wrote: May I ask what String.prototype.contains accomplish with a regular expression (that we don't already have with `RegExp.test`)? Consistency with the other methods, maybe? It would be bad API design to insist on there's only one way to do it at the expense of consistency and the principle of least astonishment. -j ___ 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: `String.prototype.contains(regex)`
I agree both with what Jason said and what Andrea said, It needs to be consistent and I think the way Andrea suggests is the correct one. If anything, I'd expect all of them to throw when passed multiple arguments for forward compatibility. It might be useful to check multiple values in contains/endsWith/startsWith or constrain it in some way. Benjamin On Wed, Dec 18, 2013 at 11:59 PM, Andrea Giammarchi andrea.giammar...@gmail.com wrote: then none of them should throw, imho startsWith is like dropping the `/^` form a `RegExp`, endsWith like dropping the `$/` part .. that's it The problem with RegExp is usually the safe escaping, having 1 char less to type for a `.test()` - so actually counting chars in the method name is even more - is not a win In `/^th(is|at)$/.test(str)` the useful `RegExp` part is in the middle so what was the reason to not coerce to string as basically every other `String.prototype` method does already if consistency was actually the reason ? Is it because split accepts `RegExp` too ? 'cause that's completely different scenario. On Wed, Dec 18, 2013 at 1:01 PM, Jason Orendorff jason.orendo...@gmail.com wrote: On Wed, Dec 18, 2013 at 11:16 AM, Benjamin (Inglor) Gruenbaum ing...@gmail.com wrote: May I ask what String.prototype.contains accomplish with a regular expression (that we don't already have with `RegExp.test`)? Consistency with the other methods, maybe? It would be bad API design to insist on there's only one way to do it at the expense of consistency and the principle of least astonishment. -j ___ 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: About Array.of()
Well, even it's confusing it's still better than `of` for the use case, and
some other alternatives:
Array.fromItems // fromXXX has another benifit that alternative constructors
(String.fromCharCode, Array.from) all begin with `from`
Array.fromList
Array.fromArguments
Array.newArray
Array.makeArray
Array.theFixedConstructorWithoutGotchas
I like the last one ;) what about you?
Of/from the alternatives proposed, I find `Array.fromArguments` compelling,
because it is self-descriptive once you know what does `Array.from`:
Array.fromArguments = function() { return Array.from(arguments) }
Remarkably, `Array.fromElements` sounds particularly bad to my ears, because it
seems to be a synonym of `Array.from` when applied to an array. (Array from
[the] elements [of] ...)
Personally, I'd not thought that `Array.of` would be a problem, but apparently,
since even people that are fine with that name tend to mingle it with
`Array.from`...
That was my two cents.
—Claude
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Re: Why thenables?
On Wed, Dec 18, 2013 at 3:32 PM, Ѓорѓи Ќосев gorgi.ko...@gmail.com wrote: I understand that adding branding to promises is impossible at this point, as it would break backward compatibility with all existing implementations. That wasn't the overriding consdieration. I don't care if we don't have a-priori compatibility. The bigger issue is the lack of symbol infrastructure in the language and the inability to polyfill if we do. I've long argued for ghetto branding (something less foot-gun-ish than an extractable then callable), but in the interest of harmony, was not willing to fight for the better design at the end. Our primary goal here needs to be shipping something ASAP. All other concerns are, in the scheme of things, irrelevant.' We're already half a year late on this. However, thenable assimilation could still be made slightly less sad by doing something very similar to branding, without breaking backward compatibility. The assimilation procedure could check if the thenable has a property that brands it non-assimilatable, e.g. __notPromise__ If such a property exists and is set to true, it will not assimilate it. While far from perfect, this will at least allow objects from existing libraries that have a .then method to coexist with promises without forcing library authors (and users) to massively refactor their code. Authors would only need to add the flag __notPromise__ to their prototypes - all other existing code will continue to work normally. I believe this would be better than globally banning such a generic name like `.then` as a method. As a bonus, statis analysis tools could possibly warn users to explicitly add `__notPromise__ = false;` (i.e. they could advise users to explicitly express intent WRT to assimilation) Does this sound like a good idea? ___ 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: Re: Why thenables?
On 18 Dec 2013 18:20, Andrea Giammarchi andrea.giammar...@gmail.com wrote: Alex can I ask you if there's any specific deadline you are talking about? Promises aren't important. They are a tool. And the design space is *clearly* overconstrained. Anyone paying attention can see that. We should have given rough consensus blessing in april and not have deprived ourselves of promises as a tool in API design for the last 7 months as a result. Your answer sounds like rushed is better than nothing ... which usually might/kinda works for web-agencies but not for would like to be corporate ready/oriented specifications, right ? No. Not with overconstrained API that is clearly a bridge to syntax, not a final destination. This committee has committed half a year of lost opportunities *for the entire platform* on the basis of pathological standards behaviour. This group has poor facility with the costs because we are far too disconnected from our users. And no. I am not happy. Sorry but I think that should be slightly ;-) more elaborated, if possible, thanks. Quick One for Ѓорѓи : markdown is awesome but in this very specific ML I find easier to read `**notPromise**` when bold is meant, than `__notPromise__` ... you know, `__proto__` and sh...tuff ^_^ unless you didn't really mean `__notPromise__` where in such case I think the `tick` should do it - sorry for the Off Topic, I was just reading through ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Why thenables?
On 12/19/2013 02:56 AM, Alex Russell wrote: On Wed, Dec 18, 2013 at 3:32 PM, Ѓорѓи Ќосев gorgi.ko...@gmail.com mailto:gorgi.ko...@gmail.com wrote: I understand that adding branding to promises is impossible at this point, as it would break backward compatibility with all existing implementations. That wasn't the overriding consdieration. I don't care if we don't have a-priori compatibility. The bigger issue is the lack of symbol infrastructure in the language and the inability to polyfill if we do. I've long argued for ghetto branding (something less foot-gun-ish than an extractable then callable), but in the interest of harmony, was not willing to fight for the better design at the end. This doesn't need symbols at all, and it could be considered a bugfix addition - there is still time for those, I believe? It would make `.then` in the method name position less of a language keyword. Without breaking compatibility with existing implementations. It will also pave the path towards a future where most implementations inherit from built in promises and those that don't set their `prototype.__notPromise__ = false`, If (and when) such a future arrives, the switch can be potentially flipped to assume `true` instead of `false`, thereby essentially removing the quirk from the language - completely. Our primary goal here needs to be shipping something ASAP. All other concerns are, in the scheme of things, irrelevant.' We're already half a year late on this. Should the language really ban all objects from using `.then`, forever? Should it force library authors to face the decision: - my objects remain incompatible with promises (cannot be returned by them), or - rename `.then` method, do a massive refactor, also force all my users to do a massive refactor Why not provide a harmless third option? - add __notPromise__ flag to my prototype to tell promises not to assimilate these objects ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Why thenables?
On 18 Dec 2013 20:27, Ѓорѓи Ќосев gorgi.ko...@gmail.com wrote: On 12/19/2013 02:56 AM, Alex Russell wrote: On Wed, Dec 18, 2013 at 3:32 PM, Ѓорѓи Ќосев gorgi.ko...@gmail.com wrote: I understand that adding branding to promises is impossible at this point, as it would break backward compatibility with all existing implementations. That wasn't the overriding consdieration. I don't care if we don't have a-priori compatibility. The bigger issue is the lack of symbol infrastructure in the language and the inability to polyfill if we do. I've long argued for ghetto branding (something less foot-gun-ish than an extractable then callable), but in the interest of harmony, was not willing to fight for the better design at the end. This doesn't need symbols at all, and it could be considered a bugfix addition - there is still time for those, I believe? It would make `.then` in the method name position less of a language keyword. Without breaking compatibility with existing implementations. It will also pave the path towards a future where most implementations inherit from built in promises and those that don't set their `prototype.__notPromise__ = false`, If (and when) such a future arrives, the switch can be potentially flipped to assume `true` instead of `false`, thereby essentially removing the quirk from the language - completely. Our primary goal here needs to be shipping something ASAP. All other concerns are, in the scheme of things, irrelevant.' We're already half a year late on this. Should the language really ban all objects from using `.then`, forever? Should it force library authors to face the decision: - my objects remain incompatible with promises (cannot be returned by them), or - rename `.then` method, do a massive refactor, also force all my users to do a massive refactor Why not provide a harmless third option? - add __notPromise__ flag to my prototype to tell promises not to assimilate these objects That's an inverse form of ghetto branding. But it doesn't matter either. The only thing that does is having *one*, *standard* contract -- and we are past due on that. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Re: Why thenables?
Thanks for the clarification and FWIW, yeah ... I agree with you but I also appreciate the effort everyone is putting trying to bring new features that are as platform agnostic as possible ... but then again, we have real life/devs/code screaming for solutions ASAP Devs also complain about mistakes though .. not sure how to win here :-( Cheers On Wed, Dec 18, 2013 at 8:18 PM, Alex Russell slightly...@google.comwrote: On 18 Dec 2013 18:20, Andrea Giammarchi andrea.giammar...@gmail.com wrote: Alex can I ask you if there's any specific deadline you are talking about? Promises aren't important. They are a tool. And the design space is *clearly* overconstrained. Anyone paying attention can see that. We should have given rough consensus blessing in april and not have deprived ourselves of promises as a tool in API design for the last 7 months as a result. Your answer sounds like rushed is better than nothing ... which usually might/kinda works for web-agencies but not for would like to be corporate ready/oriented specifications, right ? No. Not with overconstrained API that is clearly a bridge to syntax, not a final destination. This committee has committed half a year of lost opportunities *for the entire platform* on the basis of pathological standards behaviour. This group has poor facility with the costs because we are far too disconnected from our users. And no. I am not happy. Sorry but I think that should be slightly ;-) more elaborated, if possible, thanks. Quick One for Ѓорѓи : markdown is awesome but in this very specific ML I find easier to read `**notPromise**` when bold is meant, than `__notPromise__` ... you know, `__proto__` and sh...tuff ^_^ unless you didn't really mean `__notPromise__` where in such case I think the `tick` should do it - sorry for the Off Topic, I was just reading through ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
