<div id="__MailbirdStyleContent" style="font-size: 10pt;font-family: Arial;color: #000000">
                                        
                                        
                                            
                                        
                                        
                                        Hi Chris,<div><br></div><div>a good exercise would be to read unfamiliar code on a regular basis. Unfortunately, there not many hard, objective metrics to asses readability. So, there are mostly opinions and customs. As a consequence, my argument for readability cannot be flawed in a general sense. ;-)</div><div><br></div><div>Here is another summary of my thoughts:</div><div><br></div><div>- #joinSeparatedBy: concatenates elements in collections of some stable order.</div><div>- For other collections, a debugger would appear showing MNU.</div><div>- The programmer can now notice and asses the unstable order of that collection.</div><div>- The programmer can then choose to change the kind of collection (1) somwhere meaningful in the program or (2) directly before that join operation to make some order explicit.</div><div><br></div><div>If it is just for debugging, an extra #asArray wouldn't hurt. If it is for production code, such inadvertent instability of collection order can make the live unnecessarily hard.</div><div><br></div><div>Of course, Chris, you can read this as just another opinion of mine. You can also try to explain your two points somehow: (1) How big is that performance impact in your daily code? (2) Why don't you like the idea of making stable order in a collection more explicit somewhere in the code?</div><div><br></div><div>Best,</div><div>Marcel</div><div class="mb_sig"></div>
                                        
                                        <blockquote class="history_container" type="cite" style="border-left-style: solid;border-width: 1px;margin-top: 20px;margin-left: 0px;padding-left: 10px;min-width: 500px">
                        <p style="color: #AAAAAA; margin-top: 10px;">Am 05.06.2019 23:40:22 schrieb Chris Muller <asqueaker@gmail.com>:</p><div style="font-family:Arial,Helvetica,sans-serif">Hi Marcel,<br><br>You're free to write your code the way you feel you need to, but I<br>hope going forward you'll allow others to do the same.  Even if your<br>readability argument wasn't so flawed, trying to force others to write<br>what you think is good code is utterly futile.<br><br>I'll keep it in Collection in my Base package for now.  Just so you<br>know, it IS a common case to need it for non-seq collections -- it's<br>how this whole discussion got started, remember?<br><br> - Chris<br><br>> -1 for moving #join etc. up to Collection. You seem to favor some performance improvement over code readability. Making the order of the collection explicit before joining it feels more robust. #joinSeparatedBy: on non-sequencable collections has to much potential for bugs and unreadable code. See http://forum.world.st/The-Inbox-Collections-ct-827-mcz-tp5099876p5099964.html -- Having a non-seq. collection to join should not be a common case.<br>><br>> -1 for mixing up separate concerns in a single commit. Please, try separating those things.<br>><br>> Best,<br>> Marcel<br>><br>> Am 05.06.2019 00:14:53 schrieb Chris Muller <asqueaker@gmail.com>:<br>><br>> Hi Nicolas,<br>><br>> > I don't much like WriteStream on: String empty.<br>> > If String empty is implemented as answering a literal, and WritStream implemented to become the grown contents as it originally did in st80 and could also do in Squeak now that we have a fast become, we take the risk to modify the literal...<br>><br>> We both know that's not going to happen. #empty has been a class-side<br>> constructor/accessor on several classes for a long time, with > 100<br>> senders in trunk alone. It's an integrated part of the<br>> class-library's API which improves performance and readability. Any<br>> attempt to switch back to a become implementation for growing internal<br>> collections would spoil that API everywhere.<br>><br>> > String new better express our intention, we want a new substring.<br>><br>> But sometimes we trade intention-revealingness for performance.<br>> That's what this is.<br>><br>> I would offer the compromise of WriteStream on: '', but with #empty<br>> being an integrated part of the API, it's the intent as everywhere<br>> else it's used.<br>><br>> > Also, contents does not necessarily answer a copy,<br>><br>> But it does. WriteStream>>#contents answers a #copyFrom:to: and even<br>> the comment says "Answer with a copy ..."<br>><br>> - Chris<br>><br>><br><br></asqueaker@gmail.com></div></blockquote></div>