On Wed, Dec 5, 2012 at 2:02 PM, Andrea Giammarchi < andrea.giammar...@gmail.com> wrote:
> let's summarize then: > > 1. ~Weak/Map#set and Set#add returns void > 1.1 void as return is considered useless > > 2. cahinability looks like the most common pattern so those methods > should return `this` > 2.1 example: return map.has(key) ? map.get(key) : map.set(key, > operation()).get(key); > 2.2 useful to set and send same object > 2.3 chainability might lead to bad readability > > 3. Smalltalk returns the value with #put and few here think that should > be the best thing to return > 3.1 example: return map.has(key) ? map.get(key) : map.set(key, > operation()); // as result of operation() > 3.2 above example to simulate the equivalent of this common operation: > return obj.hasOwnProperty(key) ? obj[key] : (obj[key] > = operation()) > 3.3 useful to set without addressing values generators/creators > returning them anyhow since the map reference is already known > 3.4 Map and WeakMap are used as storages so always referenced while > set values do not have necessarily to be addressed (boring, problematic, > global pollution without strict, let vs var, common problems we all know > with references) > > obj.set(key, value) might reflect (obj[key] = value) semantic rather than > ((obj[key] = value), obj) which is not semantic but apparently the most > used pattern with all libraries out there except Dojo that agreed on > Smalltalk approach. > > Also HTMLElement#appendChild(newChild) where newChild is returned is more > familiar but sometimes we need to append more children so that `this` might > be more appropriate return. > > Last, but not least, no pattern blocks anyone to reach same goals inline: > > get the value > void: return map.set(key, value) || value; > this: return map.set(key, value).get(key); > value: return map.set(key, value); > > get the instance > void: return map.set(key, value) || map; > this: return map.set(key, value); > value: return map.set(key, value), map; > void and value prevent all of the following: Add value to the Set and get a fresh iterable for the keys, values, entries: set.add( value ).keys(); set.add( value ).values(); set.add( value ).entries(); Add value to the Set and send each value in the set to another operation: set.add( value ).forEach( item => ...send to some operation.... ); Add value to the Set and spread into an array of unique items: [ ...set.add(value) ]; // [ v, v, v, ... ] ...and same for Map While I completely agree that there is much to learn from other successful languages and the patterns that they were designed on, I also believe whole-heartedly in Allen Wirfs-Brock's prediction of JavaScript as the dominant programming language in the coming decades[0]. In this belief, I feel very strongly that JavaScript is in a position to evolve itself from within—yes, Smalltalk returned the value, but this doesn't mean that JavaScript should ignore the patterns that emerged in its own ecosystem, developed around its own capabilities for the sake of appeasing Smalltalk. I'd argue that most people who write JavaScript and receive a paycheck for doing so, have never written Smalltalk and most never will. (This statement is in no way a judgement of Smalltalk) Rick [0] http://qconlondon.com/london-2012/presentation/JavaScript%20Today%20and%20Tomorrow:%20Evolving%20the%20Ambient%20Language%20of%20the%20Ambient%20Computing%20Era > > br > > > > > > > On Wed, Dec 5, 2012 at 10:17 AM, Rick Waldron <waldron.r...@gmail.com>wrote: > >> >> >> >> On Wed, Dec 5, 2012 at 1:04 PM, Mark S. Miller <erig...@google.com>wrote: >> >>> On Wed, Dec 5, 2012 at 1:50 AM, Jussi Kalliokoski >>> <jussi.kallioko...@gmail.com> wrote: >>> > My 2 cents against the windmills... >>> > >>> > I personally think returning `this` in absence of any meaningful value >>> (and >>> > chaining in general) is a bad pattern. Chaining leads to worse >>> readability >>> > (there's nothing subjective about this, if you have to scan the code to >>> > another page to figure out which object the code is interacting with, >>> it's >>> > bad readability) >>> >>> This is an excellent point, and has changed my mind. I return to not >>> supporting the "return this" for these cases. Thanks. >>> >> >> In the cases that we identified as qualifying for the criteria that you >> established at the meeting, a "chain" will most likely only have one more >> method call or property access after .set()—any of the iterable producing >> methods (keys, values, entries), forEach, or the size property. But this >> also now makes any operation where I want to mutate the map/set and >> immediately do something with that object a two part exercise. >> >> "some people will misuse it" can be the argument for anything, that >> doesn't make it a strong or meaningful argument. >> >> cc'ing Doug Crockford, Erik Arvidsson, Alex Russell, Yehuda Katz to weigh >> in on this. >> >> Rick >> >> >> >> _______________________________________________ >> es-discuss mailing list >> es-discuss@mozilla.org >> https://mail.mozilla.org/listinfo/es-discuss >> >> >
_______________________________________________ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
