<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Le mer. 1 janv. 2020 à 21:02, Jakob Reschke <<a href="mailto:forums.jakob@resfarm.de">forums.jakob@resfarm.de</a>> a écrit :<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div dir="ltr">Am Mi., 1. Jan. 2020 um 20:44 Uhr schrieb Nicolas Cellier <<a href="mailto:nicolas.cellier.aka.nice@gmail.com" target="_blank">nicolas.cellier.aka.nice@gmail.com</a>>:</div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_quote"><div><div>Yes, indeed, this is a slight shift of semantics.</div></div></div></div></blockquote><div><br></div><div>One could also call it not implementing the interface properly or breaking the contract ;-)</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_quote"><div>But RunArray are essentially unused (just to store Text attributes).<br></div><div>They make sense only for optimization.</div><div>So they can have their own semantic, bended to their own purpose.<br></div></div></div></blockquote><div><br></div><div>Disregarding interfaces and contracts, yes. But it may surprise someone in the future.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_quote"><div><div>It's just that we need to comment a bit more those methods.<br></div></div></div></div></blockquote><div><br></div><div>I brought this up during a naming discussion in VMMaker some time ago: some people don't read the documentation and just rely on their expectations. It might be foolish to do so, but expectations can be justified and allow you to work more efficiently. I wouldn't like to re-check the implementation of #collect: for every new Collection subclass that comes along, in particular if I don't want to look it its implementation.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_quote"><div><div>If we don't want this behavior, then we probably don't want to use a RunArray</div></div></div></div></blockquote><div><br></div><div>Sometimes you don't know what kind of collection you get to #collect: from.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_quote"><div>Introducing a different selector would mean implementing it in other collection too.</div></div></div></blockquote><div><br></div><div>

Not necessarily. Set also does not understand #before:, you must use a SequenceableCollection if you want it. Conversely if you knowingly use a RunArray (as in Text) and you want to exploit the optimization for the iteration blocks, you could use the new selector(s).</div></div></div>
<br></blockquote><div>In my case, the client class had no idea whether a RunArray would be used as storage or not.</div>So that would mean either a beautiful isSomething query, or a common selector for all the possible storage class.</div><div class="gmail_quote"><br></div><div class="gmail_quote">I could live with practically no side effects in those blocks.</div><div class="gmail_quote">It's just a matter of thinking at a different level, not at implementation level.<br></div><div class="gmail_quote">When we abuse those side effects, we let the implementation leaking.</div><div class="gmail_quote">It's like we want to do: and collect: in the same loop.</div><div class="gmail_quote">The proper way to write the example given by Christoph would be something like:</div><div class="gmail_quote"><br></div><div class="gmail_quote">    (1 to: runArray size) with: runArray collect: [:i :v | i].</div><div class="gmail_quote"><br></div><div class="gmail_quote">Using a block with side effects just is IMPLEMENTATION defined.</div><div class="gmail_quote">For example, if you do that with an Unordered collection, you'll get a different result too with #collect:as: and (#collect:)#as: too.</div><div class="gmail_quote">That's not unexpected. Enumeration order is implementation defined anyway.<br></div><div class="gmail_quote">Even if Ordered, nothing prevents a BTree implementation to use a different enumeration order too.<br></div><div class="gmail_quote"><div><br></div><div>IMO, the fact that current phrasing explicitely tells about iterating on each elements does not have to be taken too literally.</div><div>It means that the block argument is applied on a single element at a time.</div></div><div class="gmail_quote"><br></div><div class="gmail_quote">Try writing the comment without that contract in mind:</div><div class="gmail_quote"><div>    "Answer a collection like the receiver whose elements are transformed using aBlock"</div><div><br></div><div>It's not super accurate.</div><div>If we want to be more accurate and express that aBlock will be evaluated with receiver elements, one at a time, we end up with describing the implementation rather than the semantics:</div><div>    "Evaluate the block with each element of the receiver as argument"</div><div><br></div><div>Indeed, explaining how is often a way to make understand the upper level concept...<br></div></div><div class="gmail_quote">This get over-interpreted, and we have put too much expectations!</div><div class="gmail_quote">IMO, it was not the spirit of the original contract :)</div><div class="gmail_quote"><br></div><div class="gmail_quote">IMO we have to unlearn some of our biased expectations (and of course this includes myself), we have been abusing those side effects for too long.</div><div class="gmail_quote"><br></div><div class="gmail_quote">Anyway, thanks for raising this up, that's exactly what I wanted to discuss.</div><div class="gmail_quote">If we're not ready yet, this can wait.<br></div></div>