Additional cascading Map/Set/WeakMap methods?

Allen Wirfs-Brock allen at wirfs-brock.com
Sun Jan 13 20:32:39 PST 2013


On Jan 13, 2013, at 8:18 PM, Andrea Giammarchi wrote:

> 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.

New syntactic features and API design aren't alternatives or mutually exclusive. We may choose to avoid syntax design issues by not adding the syntax, but  if we have an API, we have to do API design. 

> 
>   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'

This is another valid use case that is incompatible with chaining.  Opinions will differ on which has broader utility. So,  how do we choose.  Deciding to make set/add return undefined is either a cop out on that decision or a principled stand against all such method chaining patterns.  But we know that not everybody agree with that latter position.

Allen




> 
> 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/dba0f543/attachment.html>


More information about the es-discuss mailing list