Brendan Eich wrote:
Please drop the crappy us vs. them talk. If you read this thread,
and others on esdiscuss.org, you can see TC39 did not keep ignoring
feedback. Yeesh!
In case it is not clear: Andrea is not on TC39, not us or them in
your dichotomy, and while I agree he disregarded
Andrea Giammarchi wrote:
Do we agree this class decision was a good one? Perfect, then let's
move on to another thread and discuss how things could be better from
both worlds point of view in the future.
I'm not sure why you replied to me, since I (and everyone on TC39) has
agreed to make
Good catch! I think this old decision pre-dates for-of. Cc'ing Tom.
Leon, could you please cite the bug in a followup here if you file it?
Thanks,
/be
Allen Wirfs-Brock wrote:
Thanks,
Please file a bug on this at bug.ecmascript.org
AllenOn Jan 30, 2015 8:41 PM, Leon
Announcement: ES6 class method syntax makes a non-enumerable property of
the method's name on the class prototype. That is all. :-)
/be
Brendan Eich wrote:
Herby Vojčík wrote:
Personally, I have always believed we are going down the wrong path by
switching (from the original max-in class
Boris Zbarsky wrote:
On 1/29/15 2:55 PM, Brendan Eich wrote:
Announcement: ES6 class method syntax makes a non-enumerable property of
the method's name on the class prototype. That is all. :-)
Please post to public-script-coord with the proposed plan for web idl.
I was hoping someone deeper
I recall others being confused; probably an informative note in the spec
would help.
/be
Erik Arvidsson wrote:
I looked into it in more details and I seem to have been mistaken.
*default* is just internal spec name that is needed for hoisting
FunctionDeclaration and to create the required
Mark S. Miller wrote:
Exactly correct. I didn't realize until reading your reply is that
this is all that's necessary -- that it successfully covers all
the cases I was thinking about without any further case division.
Here's another option, not clearly better or worse:
Axel Rauschmayer wrote:
So there's no need for this
There is one use case (admittedly a rather hypothetical one):
serializing the Symbol.* symbols to a text format (e.g. an encoding in
JSON).
Symbols that user-code puts into the registry do not serialize this way,
so why should the
Axel Rauschmayer wrote:
It may make sense to add them. Their identifiers would have to be as
unambiguous as possible, e.g. URIs such as
http://ecmascript.org/symbol/foo;.
Symbol.iterator and the other well-known symbols are self-same in all
connected realms. See
Mark S. Miller wrote:
The reason why the intent is unwarranted is that the descriptor omits
configurable: rather than explicitly saying configurable: true. If
the owner object already has a configurable own property of the same
name, then a defineProperty where the configurable: is omitted
Allen Wirfs-Brock wrote:
I can only speak about ES5 (don't know about ES1,2,3 but a I'm pretty sure
there wasn't a year long bake period before each of those).
Nope.
/be
___
es-discuss mailing list
es-discuss@mozilla.org
Aaron Frost wrote:
Trying to understand the cadenced release process. In the past a Final
Draft would be cut and allowed to bake for 12 months before an
Official Approval by the Ecma General Assembly. Is that 12-month bake
still going to be in place?
More like six months, really -- Allen can
Andrea Giammarchi wrote:
I've heard the delivery, delivery, delivery story before and I
haven't seen a single case where that translated into more quality as
outcome.
You make it sound like quantity goes up, or at least exceeds what can be
QA'ed by implementors and developers before being
Herby Vojčík wrote:
Personally, I have always believed we are going down the wrong path by
switching (from the original max-in class design) to making methods
defined within a class definition enumerable.
Yes, please, if possible, go back to non-enum methods. I was writing
at that time as
Andrea Giammarchi wrote:
agreed and not only, it took years before various engines fully
implemented ES5 so saying years later that an engine is fully
compliant with a year in the past feels so wrong !!!
Why is that? Where is the thread that explains this decision?
I mean ... how should I
Brendan Eich wrote:
The reason to label editions or releases is not to give marketeers
some brand suffix with which to tout or hype. It's to organize a
series of reasonably debugged specs that implementors have vetted and
(partly or mostly) implemented.
I agree it would be best if (partly
Harmony refers to the whole post-ES4 consensus-based arc of specs from
ES5 (neé 3.1) onward into the future, until done ;-). See
https://mail.mozilla.org/pipermail/es-discuss/2008-August/006837.html
ECMAScript Harmony never referred to a specific edition of ECMA-262, nor
could it. The Harmony
Andrea Giammarchi wrote:
I really don't understand ...
I'm pretty sure you do understand -- you just don't like it.
The annual cycle may fail, but that would be bad. If it works out, we
could still continue with ES6, 7, 8, etc.
I'm leery of revolutionary fanaticism of the kind that led the
Andrea Giammarchi wrote:
I particularly don't like the idea that things could be dropped or
rushed last minute just because the new years eve is coming ... this
feel like those stories with tight deadlines where management could
easily fail due over-expectations on all possible 3rd parts
.
/be
On Fri, Jan 23, 2015 at 12:39 AM, Brendan Eich bren...@mozilla.org
mailto:bren...@mozilla.org wrote:
...
This reminds me: Axel (not Alex) cannot recommend JavaScript
2015 to anything near the Ecma standard, because trademark
I wouldn't hold my breath. Sun was not ever in the mood, even when I
checked while at Mozilla just before the Oracle acquisition closed.
Also, the community cannot own a trademark.
Trademarks must be defended, or you lose them. This arguably has
happened to JavaScript. Perhaps the best course
of it.
2015-01-23 2:39 GMT+02:00 Brendan Eich bren...@mozilla.org
mailto:bren...@mozilla.org:
Andrea Giammarchi wrote:
I particularly don't like the idea that things could be
dropped or rushed last minute just because the new years
eve is coming ... this feel
Firefox's engine has an ES4-era prototype `let` implementation, a bug to
fix by implementing ES6 semantics.
https://bugzilla.mozilla.org/show_bug.cgi?id=950547
/be
Francisco Tolmasky wrote:
Apologies as I believe this has been discussed before (
Domenic Denicola wrote:
I believe the cutover was decided in the September 25 meeting.
I must have missed it if so -- do the notes record it?
As Andreas Rossberg points out, ES6 will take years to be fully
implemented. The more we speculate (lay bets), the bigger our potential
losses.
At
problematic. It is based upon and supports the misperception that
such a branded object will have all of the specified initial
characteristics of the correspond built-in.
This is a great point, which makes me want to +1 your suggestion:
Allen Wirfs-Brock wrote:
On Jan 21, 2015, at 11:03 AM, Brendan
Brendan Eich wrote:
Sure -- good point, I flinched and was slot
slow, lulz.
/be
to say internal property because we all don't like infernal slots. ;-)
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Allen Wirfs-Brock wrote:
On Jan 21, 2015, at 9:34 AM, Brendan Eich wrote:
Allen Wirfs-Brock wrote:
There is no such thing as a symbol valued property key that is not exposed
via reflection.
Sure -- the idea was to make the symbol spec-internal, even use an abstract operation rather
Allen Wirfs-Brock wrote:
There is no such thing as a symbol valued property key that is not exposed via
reflection.
Sure -- the idea was to make the symbol spec-internal, even use an
abstract operation rather than a symbol -- anything to provide a spec
hook for WHATWG/W3C specs to build on,
ECMA-357 (E4X) pioneered informative-first prose sections, not found in
ECMA-262 Ed. 3, and as a direct consequence, had too many imprecise or
even inaccurate informative notes, which (turns out) were misread as
normative, or simply otherwise caused confusion.
Thanks for looking into fixing
Domenic Denicola wrote:
https://www.google.com/search?q=site%3Aesdiscuss.org+Array.prototype.contains+solutions
leads tohttps://esdiscuss.org/topic/array-prototype-contains-solutions which
is probably what you were thinking of.
They were not very good ideas.
It's a hard problem.
Domenic Denicola wrote:
From: Brendan Eich [mailto:bren...@mozilla.org]
Can we get a leg up, rather than wait for a f2f? This thread seems fine for
further discussion and simplifying proposals.
Well, to be clear, I'd prefer we not change anything at all. It's too late to
be tweaking
Mark S. Miller wrote:
IIRC David Ungar's question to Tom was why not enable proxies to
mega-program every base-level operation in the language? I took
this to mean nothing like a nominal type check could evade
proxying, in David's vision. Is this plausible in your view?
No it
Mark S. Miller wrote:
Yes, we want to complete the MOP so nominal types are equivalent
to branded structural types, a la Modula 3, and per David Ungar's
position articulated many times over the years (I heard David say
it to Tom Van Cutsem in person at SPLASH 2011, re: Proxies
Mark S. Miller wrote:
Hmm, maybe -- but does Self have a reference-identity
equivalence-relation operator that can't be spoofed? Might help to
ask David, but to abstract from that particular SPLASH 2011 QA,
obviously we won't be enabling such fakery in JS.
I don't get it.
Mark S. Miller wrote:
I understood and agree with everything (or close enough) until your last:
On Tue, Jan 20, 2015 at 7:20 PM, Brendan Eich bren...@mozilla.org
mailto:bren...@mozilla.org wrote:
ISTM we need more definite consensus on branding to finish off
toStringTag in ES6
Mark S. Miller wrote:
On Tue, Jan 20, 2015 at 4:44 PM, David Ungar un...@mac.com
mailto:un...@mac.com wrote:
Oh, the troubles with email.
I’ll try again:
Self stratifies things into base- and meta- level. The idea is
that almost all code is better off sticking to base level
Ryosuke Niwa wrote:
Having said that, TDZ was introduced to give let, const, and alike
a sensible behavior as I understand it. Since this was never
defined by let or const, it seems a little arbitrary and
inconsistent to make this TDZ only inside a derived class's constructor.
It's not
Brendan Eich wrote:
2. Any remaining brand or trademark test can use object identity or
equivalent unforgeable capability.
(2) can't be meta-programmed to spoof identity.
Reference identity, of course -- value types/proxies want value identity
defined by concatenating and freezing existing
Mark S. Miller wrote:
Good, I understand now. I agree with all this. In ES6 the common cases
have to work right, and no guarantees compromised. Beyond the common
cases, extensibility we're confident in is great now. Otherwise, place
restriction where needed now (static and dynamic errors,
Kevin Smith wrote:
They're currently spec'ed to throw. I wouldn't change that for
ES6. It could change in the future.
Granted.
However, I don't think we should consider the design complete without
an answer to this question, regardless of what gets specced for ES6.
The answer
Can we get a leg up, rather than wait for a f2f? This thread seems fine
for further discussion and simplifying proposals.
/be
Domenic Denicola wrote:
I think we should remove those anti-spoofing protections. I anticipate a
discussion at TC39 next week.
Dmitry Soshnikov wrote:
```js
let [x,y] = set; // x='a'; y='b’;
```
Would this work actually? :) Destructuring does get property, which
wouldn't call set's `get` method.
See
Allen Wirfs-Brock wrote:
see https://bugs.ecmascript.org/show_bug.cgi?id=3574
already fix in my working draft
Ok, so the ToObject always runs first. Sounds better on short reflection
-- thanks!
/be
___
es-discuss mailing list
Why should it throw if there's no [[Get]]?
Consider let {x} = o as short for let x = o.x (with o evaluated once and
first, in the general case, of course). Then the empty object pattern
does nothing and should not throw.
This seem best for generated code purposes, it gives a more general
Frankie Bagnardi wrote:
I'm also expecting a lot of questions about 'what is this new.target
thing in this code?', 'is new a variable?', 'where does it come
from?', 'isn't new an operator?', etc.
if (this instanceof MyDate) ...
... is clearer, but I guess it needs to be disallowed because of
Fabrício Matté wrote:
I agree with Frankie. Assume a developer who has never seen this
`new.target` construct before.
In general, ES6 has new syntax, so this is a learn it and use it bump,
one of many.
They will first think that this is an invalid expression, as `new` is
an operator. Then,
Gotta agree new.target is nicer to read and write!
/be
Allen Wirfs-Brock wrote:
err,
try {
let thisValue = this; //can't reference 'this' prior to
'super()' in a [[Construct]] call of a derived function
} catch (e} {
calledAsFunction = false //no
Before we go tl;dr on this topic, how about some data to back up the
asserted problem size? Filip gently raised the question. How much memory
does a realm cost in top open source engines? Fair question, empirical
and (I think) not hard to answer. Burdened malloc/GC heap full cost, not
net
Indeed, in my first reply on-thread, I wrote
This is exactly the reason.
to acknowledge existing consensus. Thanks for linking!
/be
Domenic Denicola wrote:
I re-read through this whole thread and realized nobody brought up the fact that
this*specific* change, of making `String(symbol)`
Allen Wirfs-Brock wrote:
ObjectLiteral is already doing double duty covering ObjectAssignmentPattern.
so this would be even more complexity in this area of the grammar.
Yeah, the complexity counter-argument is strong.
Finally, I'm sort of on the side that this may not be so good for
Allen Wirfs-Brock wrote:
On Jan 6, 2015, at 5:34 PM, Gary Guo wrote:
I found that even without shorthand, the object literal can still be
ambiguous with block.
Yes, but not in the context of a ConciseBody of an ArrowFunction.
The grammar for ConciseBody
Dean Landolt wrote:
On Tue, Jan 6, 2015 at 3:57 PM, Marius Gundersen gunder...@gmail.com
mailto: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
Isiah Meadows wrote:
Okay: is this a valid statement/expression? I didn't think so, but I
may be wrong.
```js
({ foo(); bar(); })
```
It's a syntax error, in any JS repl or standard.
The Node repl only removes parens if it tries adding them first around
braced input and that fails.
Marius Gundersen wrote:
I don't see how wellLabeledStatement will protect against object
literals with shorthand properties, like (x, y, z) = {x, y, z}.
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
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
Dean Landolt wrote:
ISTM there's consensus that this is a footgun -- isn't that a kind of
spec bug?
No, it's a trade-off, and recent comments in this thread argue against
complicating the grammar and real-world parsers, and in favor of
teaching people to parenthesize. Nowhere near consensus
Mark Volkmann wrote:
My apologies. I meant to say that Traceur doesn't support returning a
literal object from an arrow function with syntax like this:
let f = x = ({foo: bar});
However, I just tested it again and it works fine. I could swear this
didn't work a few months ago. Maybe it was
Frankie Bagnardi wrote:
That's good news, thanks for the strawman link. Is it correct to
assume this with that proposal?
var f = (x) = (y) = {x, y};
f(1)(2) // = {x: 1, y: 2};
Good point, the strawman does not take object literal shorthand into
account and indeed parses {x, y} in an
Kevin Smith wrote:
I think hacking around this would not get rid of the footgun, but
would just make it more complicated to understand the footgun,
personally.
My gut reaction is to agree - the current rule, while it takes some
trivial learning, is easy to understand and
Domenic Denicola wrote:
What do you think the chances of this are in ES7+? That is, how
backward-compatible is this change? The linked strawman doesn't seem to touch on
`() = { foo: bar }` as a back-compat hazard.
The strawman discusses compatibility explicitly:
Caitlin Potter wrote:
The strawman changes to the grammar are still ambiguous :(
`() = {}` - noop or Object or SyntaxError? If SyntaxError, ...why?
No, the strawman addresses this: An empty pair of braces |*{}*| other
than at start of /Statement/ is an /ObjectLiteral/. The grammar is
Brendan Eich wrote:
Kevin Smith wrote:
I think hacking around this would not get rid of the footgun, but
would just make it more complicated to understand the footgun,
personally.
My gut reaction is to agree - the current rule, while it takes some
trivial learning, is easy
Andrea Giammarchi wrote:
A generic description-aware `Reflect.describe(genericObject)`like
approach seems way more useful for logging annd debugging purpose than
a footgun in the wild.
Good idea, should find an ES7 champion. If we had this, I think we could
have made String(sym) throw, and
Alex Kocharin wrote:
My point is: concatenating Symbols with other strings have
legitimate
uses.
Name one.
I did name one in another message. Logging.
That's a use-case for some way (could be concatenation, but as noted the
downside risk is huge; could be a new Reflect
Claude Pache wrote:
Now, it will be argued that it would be a precedent to make such a distinction
between implicit and explicit coercion, for, until ES5, there is none.
Kind of there all along, as noted up-thread:
js o = {valueOf(){return 42}, toString(){return 'haha'}}
({valueOf:function
Axel Rauschmayer wrote:
On 03 Jan 2015, at 19:52, Brendan Eich bren...@mozilla.org
mailto:bren...@mozilla.org wrote:
None of the objects in the examples bz cited are Arrays -- what did
you mean?
When I though of `+` being used inside square brackets, I only thought
of strings
Rick Waldron wrote:
Subjectively: I think it's nice in theory, but bad in practice.
Compared to what? Converting a symbol to asilent-but-deadly string?
I thought you were gonna raise the other way to restore consistency:
make String(sym) throw too. Then we'd need a new Reflect op to get a
Rick Waldron wrote:
That example above is pretty compelling for throw always consistency.
With a new Reflect.* API for converting a symbol to its
diagnostic/debugging string?
If you agree, please file a bugs.ecmascript.org ticket.
/be
___
Nevertheless,
https://bugs.ecmascript.org/show_bug.cgi?id=3477#c12
makes a good point. IMHO!
/be
Caitlin Potter wrote:
I agree on that point, and therefore I didn't make any refactoring
argument.
I was referring specifically to C12 (and one other, IIRC)
I was referring
Alex Kocharin wrote:
The code will be incorrect if you pass any regular object in there.
Why should symbol be any different?
For me, its throwing behavior is just another thing that could crash
server-side node.js process for no good reason.
No good reason? Wrong.
Just because bugs pass
Alex Kocharin wrote:
04.01.2015, 05:44, Rick Waldron waldron.r...@gmail.com:
On Sat Jan 03 2015 at 9:41:57 PM Alex Kocharin a...@kocharin.ru
mailto:a...@kocharin.ru wrote:
Also, if you want to prevent mistakes like `object['blah' +
symbol]`, linters could be changed to forbid/warn
Caitlin Potter wrote:
One reason it might make sense to throw, is people converting values
to string names for use as object properties. Reason you'd want to
throw would be to prevent accidentally making the key useless
(different from its original Symbol value).
This is exactly the reason.
Somehow the thread forked, and I see Kevin Smith already wrote a reply
on the other branch like mine -- sorry about that. But how did the
thread fork?
/be
Brendan Eich wrote:
ES5 has Object static methods for getting all own property names,
enumerable or not. Also walking prototype chain
Glen Huang wrote:
I think I had been doing the whole thing wrong.
That is unclear, but it's clear to me that template strings in ES6
(including String.raw) are expressive enough to do what you need. Confirm?
/be
___
es-discuss mailing list
Kevin Smith wrote:
I looked through my ES6 code and found a place where I was using
`Object.assign` as an simplistic mixin function.
ES5 introspection APIs are enough, and if you're mixing in from an ES6
class using old code, you face the same non-enumerable-methods surface
that you would
Kevin Smith wrote:
Here is the summary:
Total Files Read: 11038
Files Containing Explicit 'enumerable: false': 149
Occurrences of 'enumerable: false' (and variants): 206
I love this kind of analysis - thanks!
Agreed, 3 -- thanks, Rick!
My interpretation of this data is
Brendan Eich wrote:
There's a confounding variable: the pain of ES6s meta-object APIs, in
all respects.
I meant ES5's here, of course.
Agree with Jeremy, laziness is a programmer virtue and a part of human
nature. People are not bothering where they don't know better, or do
perhaps know
Caitlin Potter wrote:
Supposing that methods were non-enumerable by default, would accessors be
different, or also non-enumerable by default?
Non-enumerable, to match built-ins (RegExp.prototype has some notable
accessors).
/be
___
es-discuss
Boris Zbarsky wrote:
3) Try to make all DOM stuff non-enumerable, dealing with compat
issues by adding [LegacyEnumerableProperties] in the few cases where
they arise. This risks landing us in the same place as #2 depending
on how many interfaces need the annotation, plus compat fallout as we
Axel Rauschmayer wrote:
The alternative is to treat enumerability the way ES6 treats holes:
pretend it doesn’t exist:
That doesn't work, here or for holes. We've actually split APIs with
respect to holes, and this will mean bugs. We did make an intentional
future-trumps-past choice against
Sorry, you can't use small-world reasoning about programming in the
large, especially with JS on the web. for-in proliferated, before
hasOwnProperty appeared in ES3. Even after, the burden was high enough,
per that study Allen cited
Boris Zbarsky wrote:
-- so I think the right attack is on the quirky DOM.
I think the fundamental assumption that the DOM is quirky is broken.
Something is quirky if we want mostly-consistent non-enumerability of
proto-methods/accessors. Either core built-ins, or DOM. Sorry if
quirky
Oops, you're right in these cases. The CheckIterable spec helper seems
over-general. Allen?
/be
Gary Guo wrote:
Date: Mon, 22 Dec 2014 21:28:54 -0800
From: bren...@mozilla.org
Your suggestion breaks Array.from and TypedArrayFrom.
In the spec:
8. Let arrayLike be ToObject(items).
A
Perhaps the most elegant way is functional composition on arrays, not
string hacking just-so imperative coding: zip composed with flatten and
join. You could even use underscore.js:
http://underscorejs.org/#flatten
http://underscorejs.org/#zip
but JS's OO standard library style prefers method
It ain't over till it's over. If we can't tweak ES6 to fix a mistake,
just because process, then we're doing it wrong. OTOH the bar for any
change, including what is regarded by many (but not all) as a fix, is
very high.
We should take advantage of es-discuss to debate the crucial question,
Clever -- treat the cooked values as raw. Should work -- test in Traceur?
/be
Glen Huang wrote:
On second thought, make it could be just as simple as this?
function tag(templateObj, ..args) {
return String.raw({raw: templateObj}, …args);
}
Jeremy Martin wrote:
In all the discussions I've observed, the primary argument for
enumerability has been consistency with ES5 prototype conventions. I
don't think I've seen a single argument in favor, though, based on the
actual intrinsic merits of that behaviour.
Right, hence my tweet
Your suggestion breaks Array.from and TypedArrayFrom.
/be
Gary Guo wrote:
I suggest we can a little bit combine these steps:
CheckIterable (obj)
1. Let box be ToObject(obj).
2. ReturnIfAbrupt(box).
3. Return the result of calling the [[Get]] internal method of box
passing @@iterator and
Till Schneidereit wrote:
On Thu, Dec 18, 2014 at 6:15 PM, Mark Miller erig...@gmail.com
mailto:erig...@gmail.com wrote:
I didn't know that SpiderMonkey did that, but I agree it is better. In
light of this news, I'm glad my code sample doesn't work ;).
As for would be good for all
Allen Wirfs-Brock wrote:
On Dec 16, 2014, at 10:49 AM, Rick Waldron wrote:
Allowing configurability of the value of a built-in object's
@@toStringTag property has the (likely undesirable) side effect of
making calls to Object.prototype.toString.call(o) unreliable.
Illustrated here:
It should go without saying I'm not proposing an ES6 change. This is all
just es-discuss discussion, at most informative for future editions.
Allen Wirfs-Brock wrote:
I suspect people (some of 'em;-) will want consistent high-integrity
toStringTag.
They can make the toStringTags they care
Kevin Smith wrote:
```js
export default function a() {}
a = 2;
```
(This should be 2, right?)
I *think* the default binding in this case would still point to the
function. I find this particular example completely baffling, to be
honest.
This seems clear. As Dave
Ah, thanks -- I remember someone pointing this out, now that you mention it.
My misunderstanding in the last two posts dings my ES6 quiz score! Who
will get a perfect score in a fresh (uncoached) quiz setting? Is this
telling us something? Anyway, I agree that `export default function a()
{}`
Tab Atkins Jr. wrote:
JS has maps/sets that take objects natively, hiding any details about
how a mutable object is tracked/stored as keys or values, so there's
never been any need for such a thing. Explicitly exposing hash codes
is leaking implementation details into the user-facing API.
Not
François REMY wrote:
± var o = {};
± var p = new Proxy(o, { get: function(o, p) { return o[p]; } });
± o.__proto__ = p;
±
± This does nothing on its own in Firefox, afaict.
± If I then do o.foo I get a too much recursion exception, as expected.
±
± What is the problem, exactly?
I
Good point about multi-gen. Lars Hansen even researched oldest first
collection:
http://www.cesura17.net/~will/professional/research/presentations/gc/index.html
Clearly, Ungar's model was a simplification, with trade-offs as expected.
Allen Wirfs-Brock wrote:
My main take-away from this
(Nit-correcting along with comments and questions in-line, just trying
to parse what you mean, not snarking -- except for the first comment :-D.)
Allen Wirfs-Brock wrote:
On Nov 27, 2014, at 1:17 AM, Andreas Rossberg wrote:
The discussion here still makes various untested assumptions about
Allen Wirfs-Brock wrote:
WeakMap get/set/has/delete work similarly by accessing keys' inverted map
using M as the key.
[A] This means M must be mapped to WC, via some internal member or (side-)side-table.
M is an instance of a WC, eg, M is a WeakMap which is a kind of WC
Oh I see --
Katelyn Gadd wrote:
However: Does this mean that if I implement clear myself by creating
new WeakMaps, i'm inadvertently doing horrible things to the GC?
Assume yes (only defensive assumption). What goes wrong?
Sorry if I missed it: what is your .clear use case, in example code?
/be
Axel Rauschmayer wrote:
As an aside, I still feel that two concerns are mixed in a generator
function:
* The creation of the generator object. This is where the generator
function is like a constructor and where you’d expect `this` to refer
to the generator object.
Nope, not a constructor
201 - 300 of 4618 matches
Mail list logo
