keys and values are still in specs

[danielkcz]

I have just checked draft from 18th of July and these two are still in there, so why you have removed them ?

23.1.3.8 Map.prototype.keys ( )
The following steps are taken:
1.  Let M  be the  this  value.
2.  Return the result of calling the CreateMapIterator abstract operation with arguments  M  and "key".

23.1.3.11 Map.prototype.values ( ) 
The following steps are taken:
1.  Let M  be the  this  value.
2.  Return the result of calling the CreateMapIterator abstract operation with arguments  M  and "value".

[WebReflection]

those used to be Array when I've first implemented this sham … specs made them Iterator so it's pointless to polyfill them because no JS engine that does not supports natively Map and WeakMap can possibly support for/of operator.

Does this answer your question?

[danielkcz]

Well that's true, but there are things like https://github.com/termi/es6-transpiler, that can manage for-of quite nicely. I haven't tried yet that and if there is some other blocker then nevermind this.

[WebReflection]

I believe that transpiler needs special syntax in order to support iterators but that's actually a valid point. I'll try to fix this somehow soon, stay tuned.

[danielkcz]

I had also found this one ... https://www.npmjs.org/package/es6-for-of

And if you need support for Symbol, this looks quite good ... https://www.npmjs.org/package/es6-symbol

[WebReflection]

Symbol done the right way are here

[danielkcz]

Ok, guess it doesn't matter that much. Till it's written according to specs, it should be good enough to use before it becomes stable in browsers.

[WebReflection]

OK, I've had a better look at what specs say and methods implemented here and there … it's more work than expected. If you are in a rush I might suggest an alternative, if not already linked in this project home. Apologies but I have not much time these days for extra maintenance :-(

[danielkcz]

Sure, let me know about alternative, it's not like everything would be dependent on this part :)

[WebReflection]

lurking around quickly, it seems that nobody got all three of them in (understandable, since WeakMap is not reliable) but the most complete polyfill seems to be the one included in es6-shim - it gives you fully specd Map and Set and should hopefully work with for/of too.

I'll keep this updated in case I'll ever find some time to add these Iterator based methods

[englercj]

Ping! Any chance of getting iterators? I literally can't use this lib because I want to use the built-in Set and fallback to a polyfill but this lib acts differently than the spec.

[WebReflection]

I am pretty sure if the engine supports for/of you have native Set in there too, right ?
I am not sure if es6-shim would be a better, more obtrusive, polyfill for iterators too.

HHave a look: https://github.com/paulmillr/es6-shim/#safe-shims

[englercj]

So I'm actually using es6-set right now, but you don't need for/of to iterate a Set:

var iterator = mySet.values();
var itVal;

while(!(itVal = iterator.next()).done) {
    itVal.value;
}

Which is basically how you have to do it if you want to use Set in browsers that implement it, and have that same code run with a polyfill (no transpiling).

[WebReflection]

if that's how you have to do it anyway, what are you gaining in terms of performance? why not just the following?

mySet.forEach(function (value) {
  // do what you have to do
});

I think es6-shim is the right way to go for a better compatibility. Transpilers might even support es6-shim fix/implementation in order to work properly, this old module was meant to introduce basic collections, not the whole new Iterator logic.

Not sure I should fix it, it seems right now overlapping or duplicated with what es6-shi fixed already.

What do you think? Why you need this module to be fixed?

[englercj]

Actually, just ran a jsperf and it looks like using .forEach and the while loop are both faster than using for/of, with the .forEach method being the fastest:

http://jsperf.com/es6-collection-iteration/8

I wasn't aware that you were deprecating this module in favor of es6-shim, the reason I don't use es6-shim is because I can't include only the set polyfill or only the map polyfill. I basically have to include everything or nothing, which is lame. I am using es6-set right now, which is 2K minified as opposed to es6-shim which is 30K. Note that I use CJS to organize my code, and since es6-shim has all the polyfills in a single file I can't include only a subset of it.

[WebReflection]

I am not necessarily deprecating this but I am not sure I want to fix the Iterator part. Iterator is a whole "thing" that if partially implemented coild break other code around. I rather stick with faster forEach also because Iterator is meant to be used with generators. I don't see any advantage in terms of performance, readability, or amount of RAM and GC operations, that would make me use a for/of instead of a forEach ... I don't see it practical, specially with Array-like structures.

Iterator is good, but not so useful with Sets or Maps, IMHO + I really don't have time to brng in a full Iterator logic that won't mess up with other possible polyfills that somehow fix Iterators in the whole env.

Hope this makes sense to you

[englercj]

@WebReflection Makes perfect sense, thanks for taking the time to explain it out. I still won't be using es6-shim for the foreseeable future, and I can't use for/of because I don't want to use a transpiler.

I want to use a set because the insert/unique check is much faster than an array, but the iteration is just so much slower (and that happens much more often in my case) so I may just switch to a pure array implementation.

[WebReflection]

if iteration is more frequent than inserting, how about this:

Array.prototype.pushUnique = function () {
  for (var tmp, i = 0; i < arguments.length; i++) {
    tmp = arguments[i];
    if (this.indexOf(tmp) < 0) this.push(tmp);
  }
  return this.length;
};

you are penalized in insertion, but you won't compromise looping, which is the frequent operation.

[englercj]

@WebReflection Which is exactly what I am going to do, I was using a set because the insertion would be more performant but I didn't realize until now just how slow the iteration was :(