Additional cascading Map/Set/WeakMap methods?

Andrea Giammarchi andrea.giammarchi at gmail.com
Sun Jan 13 20:18:28 PST 2013


Allen the cascading thing is usually leading to think everything is
cascading and there will always been cases where methods will break that
cascading thing ...

In these case we have .has(key) able to break the "keep going and do stuff"
with the instance.

In a direction where monocle mustaches has been applauded from any side and
where cascading stuff ain't needed anymore since this will be not ambiguous
and desired:

var another = map.{
  delete(key);
  set(other, value)
  get(another);
};

I don't see any valid reason to promote a jQuery style API for fresh new
ES6 stuff while what suggested by me and agreed by many others in the other
thread would be probably a better option against a void return.

  return map.has(key) ? map.get(key) : map.set(key, val);

Above logic is way betters, in my opinion, than a generic, pointless in
this case, 'this'

br




On Sun, Jan 13, 2013 at 8:07 PM, Allen Wirfs-Brock <allen at wirfs-brock.com>wrote:

>
> On Jan 13, 2013, at 5:14 PM, Brandon Benvie wrote:
>
> delete is supposed to return whether the item was in the collection to
> delete or not, which otherwise would require using has to check for before
> deleting. I don't know how useful the functionality is, but wanted to note
> it since it'd be lost with this change. Chaining `clear` is an easy
> definitely though.
>
>
> Cascading delete and delete with existential result are clearly
> alternatives that can't both be accommodated in the collection API.
>
> The existential result alternative is an optimization that saves doing two
> hash probes of a collection in certain circumstances. The attractive thing
> about it is that it is an optimization that you can't make in ES code if
> you only have has and and cascading delete.  So, in a perf critical
> situation it provides value that a ES programmer could not obtain without
> it.
>
> However a  has/delete sequence can be fairly easily optimized at an
> implementation level. Just cache the last hash probe and check if the next
> probe is for the same key.  But, unless it is a common perf bottleneck (or
> appears in an important benchmark) implementation are unlike to actually
> implement such an optimization.
>
> So, we can design the optimization into the Map API by having Map delete
> return a Boolean or we can have a cascading Map delete and depend upon
> implementations to optimize successive lookups of the same key, if it
> proves important.
>
> I don't yet have a strong preference between those two alternatives.
>
> Allen
>
>
>
>
>
>
>
>
>
>
>
> On Sun, Jan 13, 2013 at 7:58 PM, Tab Atkins Jr. <jackalmage at gmail.com>wrote:
>
>> On Sun, Jan 13, 2013 at 4:44 PM, Allen Wirfs-Brock
>> <allen at wirfs-brock.com> wrote:
>> > At the last TC39 meeting, it was agreed tothat the set/add methods
>> would return the collection that to which something is being added.
>> >
>> > This supports code patterns like:
>> >
>> > someMap.set(key1,value1).set(key2,value3);
>> >
>> > In making this change to the spec. I noticed several other methods that
>> could reasonably be used in this same pattern. For example:
>> >
>> > someMap.clear().set(aKey, aValue);
>> >
>> > someSet.delete(oldMember).add(newMember);
>> >
>> > Are there any objections to making the clear and delete methods of
>> Map/WeakMap/Set also return the collection, just like set/add?
>>
>> None from me.  If I was a TC39 member, I'd object to *not* adding them.
>>  ^_^
>>
>> ~TJ
>> _______________________________________________
>> es-discuss mailing list
>> es-discuss at mozilla.org
>> https://mail.mozilla.org/listinfo/es-discuss
>>
>
>
>
> _______________________________________________
> es-discuss mailing list
> es-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20130113/67ea76eb/attachment.html>


More information about the es-discuss mailing list