<QuasAtWork> my polyfill for EMCAScript 6 Symbol() seems to be working :V
<QuasAtWork> http://pastie.org/10210276
<QuasAtWork> I mean other than the unavoidable fact that you can cast them to string
<Altazimuth> How would that stop your polyfill from working?
<QuasAtWork> which I need to abuse in this example to make sure the garbage collection is working properly on the dummy properties added to Object.prototype
<QuasAtWork> see normally that would cause a memory leak
<QuasAtWork> cuz every Symbol created would add a property to Object.prototype which wouldn't go away even if all Symbol instances with that unique ID were deleted
<jmickle> i dont know whats going on here
<QuasAtWork> but I am tricksy
<Altazimuth> Ooooh memory leaks fun.
<QuasAtWork> I have a native extension object which does ref counting
<QuasAtWork> every time a Symbol() is GC'd it decs its ref to an object stored in a C++ map
<QuasAtWork> if that ref count hits 0, it deletes the corresponding dummy property off of Object.prototype
<QuasAtWork> and you can see that happen
<QuasAtWork> I delete the symbol reference itself (b)
<QuasAtWork> check the prop still exists, it does
<QuasAtWork> force GC, it still exists, because there's a reference in the array returned by Object.getOwnPropertySymbols
<QuasAtWork> so I delete the array too
<QuasAtWork> check if it still exists; it does, because GC hasn't run
<QuasAtWork> so I force GC again
<jmickle> whats the use case for this, though?
<QuasAtWork> and then you see the property no longer exists, and it throws
<QuasAtWork> cuz it can't to toSource() on undefined :P
<QuasAtWork> https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Symbol
<QuasAtWork> Symbols create private data in JavaScript more easily.
<QuasAtWork> they are unique names and are automatically non-enumerable
<QuasAtWork> they also, vis-a-vis "well known" symbols, allow certain new global APIs or "protocols" as JS likes to call them to exist
<QuasAtWork> if your object has a Symbol.iterator property, then it automatically works with things that use the iterator protocol.
<QuasAtWork> just as the chief example
<QuasAtWork> see if they defined that just as "put it at 'Symbol.iterator'" with that being a normal string property, that would inevitably conflict with somebody somewhere's already existing JavaScript library and the world would blow up
<QuasAtWork> but the actual object Symbol.iterator is something that *cannot* conflict with anybody's existing library bullshit.
<QuasAtWork> I have to simulate it with UUIDs and use actual string props, because my interpreter doesn't support this natively
<QuasAtWork> in a fully ECMA 6 compliant interpreter, a Symbol is a new 3rd kind of property and doesn't decay to a string at all
<QuasAtWork> so that's what I meant about the polyfill not being FULLY compliant, because it simply can't be from a technical POV
<QuasAtWork> but I have all the important stuff working :P
<QuasAtWork> as long as one did not abuse Symbol.prototype.toString(), which any compliant code wouldn't, you'd see the same behavior
<QuasAtWork> (again I abuse it in the example just to test that the GC of Object.prototype dummy props is working)
<QuasAtWork> the dummy props have to exist so that if you use a Symbol to assign a property to an object, it becomes non-enumerable :V