At the last f2f2 we talked about renaming WeakMap to SideTable. We
postponed the discussion, saying that we would get back to it later. We
never did.
I would like us to keep the name WeakMap as it is. We didn't really take
WeakSet into account. If we rename WeakMap we would need to rename WeakSet
On Mon, Dec 16, 2013 at 11:59 AM, Erik Arvidsson
erik.arvids...@gmail.comwrote:
At the last f2f2 we talked about renaming WeakMap to SideTable. We
postponed the discussion, saying that we would get back to it later. We
never did.
I would like us to keep the name WeakMap as it is. We didn't
Brendan and I had a side conversation the next day we should have brought
to the attention of the group. In the main discussion, we said we needed to
hear back from Luke, since WeakMap had already shipped in IE11. The next
day we did, and Brendan I agreed to drop the renaming. Which,
fortunately,
* Erik Arvidsson wrote:
At the last f2f2 we talked about renaming WeakMap to SideTable. We
postponed the discussion, saying that we would get back to it later. We
never did.
I would like us to keep the name WeakMap as it is. We didn't really take
WeakSet into account. If we rename WeakMap we
It seems to me that once again early adoption of non complete standards
wins in the short term, compromising the long one forever ...
Although IE11 promised incremental updates too and create an alias on the
global scope is not the end of the world, IMO.
We are all use to write abominations such
as the horse rightly pointed out ... please let me reformulate last
sentence:
And yes IE team, the prefix would be lowercase as any other browser is
doing, thanks.
( no MSWhateverItIs, thanks!)
On Mon, Dec 16, 2013 at 11:01 AM, Andrea Giammarchi
andrea.giammar...@gmail.com wrote:
It seems
On Dec 16, 2013, at 9:34 AM, Bjoern Hoehrmann wrote:
...
(The name SideTable makes me think I seriously need to re-evaluate
what `WeakMap` is supposed to be.)
That is what was so attractive about changing the name.
Allen
___
es-discuss mailing
The problem i have with SideTable as a name is that it’s implying a very
specific use case (one that could equally be served by private names), it’s
also not an obvious name to developers who are not aware of terms of art.
I said a long time ago that the name WeakMap did not match the expected
Le 16/12/2013 22:42, Anne van Kesteren a écrit :
If you're unclear on the name, just make it clear in the specification
that the name is not stable and that therefore it cannot ship yet (you
could implement it and ship it in nightlies and such of course).
Or don't put it in the spec at all?
(I know Anne knows this argument, but i’m emailing this logic for people who
aren’t aware of it)
The reason for prefixing APIs is to allow a feature to be shipped and used by
developers before the final api semantics are settled on. In the event the
spec doesn’t change then they simply alias,
On Mon, Dec 16, 2013 at 4:42 PM, Oliver Hunt oli...@apple.com wrote:
The problem i have with SideTable as a name is that it’s implying a very
specific use case (one that could equally be served by private names), it’s
also not an obvious name to developers who are not aware of terms of art.
Le 16/12/2013 22:51, Oliver Hunt a écrit :
(I know Anne knows this argument, but i’m emailing this logic for people who
aren’t aware of it)
The reason for prefixing APIs is to allow a feature to be shipped and used by
developers before the final api semantics are settled on. In the event the
I'm noticing that many methods added in ES5 and due in ES6 are defined on the
type's constructor function instead of on the type's prototype. For example,
Object.keys, Object.defineProperty, and Array.isArray.
Is there a reason these were not added to the prototype, i.e.
On Mon, Dec 16, 2013 at 3:24 PM, Oliver Joseph Ash
oliverj...@icloud.com wrote:
I'm noticing that many methods added in ES5 and due in ES6 are defined on
the type's constructor function instead of on the type's prototype. For
example, Object.keys, Object.defineProperty, and Array.isArray.
Is
last thought would be an answer to th epossible question:
do we need to support mozMatchSelector forever ?
NO
since matches() will do once it works as standards say
br
On Mon, Dec 16, 2013 at 3:26 PM, Andrea Giammarchi
andrea.giammar...@gmail.com wrote:
no prefix and early versions is a
How would you define Array.isArray on the Array prototype? That'd just fail
for everything that is not an array and doesn't implement isArray itself.
Things like Object.keys are reflective, enumerating over the properties of
an object (even more so in ES6) is not something you'd commonly do in
16 matches
Mail list logo
