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 <[email protected]>
> 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. <[email protected]> wrote:
>> On Sun, Jan 13, 2013 at 4:44 PM, Allen Wirfs-Brock
>> <[email protected]> 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
>> [email protected]
>> https://mail.mozilla.org/listinfo/es-discuss
>>
>
>
> _______________________________________________
> es-discuss mailing list
> [email protected]
> https://mail.mozilla.org/listinfo/es-discuss
>
>
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
