<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class=""><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On a serious note, libary methods, like that method, ought to be fast,<br>
</blockquote>
<br></span>
Every method in the image is a library method, so what do you mean by<br>
</blockquote>
<br>
Really? Explain me how Browser >> #defaultBrowserTitle, a method I chose randomly, is a library method?<br></blockquote><div><br></div><div>Well, I was actually asking for clarification from _you_  for the meaning of "library method", since you were the one assigning an "ought" to them  :).  So I started out with it meaning, "every method in the base image", as a means to open up the question of what you meant.  My own criteria is "methods which are called thousands of times per minute" _today_.  But as the guy whose done more of these sorts of method optimizations than anyone (most of which I love), I am actually *truly curious* about YOUR criteria on this.  What methods in the image would Levente prefer to be more readable than performant, and why?</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br></blockquote></blockquote><div><br></div><div>> ....</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
because you can't know in what situation they will be used. Saying that it's<br>
not even used is therefore not a valid reason.<br>
</blockquote>
<br></span>
That's only true for the very lowest-level methods.  Generally, it's<br>
better to design and code for what's known, and NOT try to code for<br>
the future / unknown.  IF and when that future comes, it'd be easy<br>
enough for you to deal with any performance issues at THAT time.  In<br>
the meantime, we "ought"  :) to keep as much beautiful minimal<br>
elegance as we can.<br>
</blockquote>
<br>
So, if I decided to write a mail transfer agent, and I found that optimizing #isAsciiString would bump the throughput by, let's say, 10%, then and only then would I be allowed to change the implementation in Squeak? Or should I keep my optimized version in my image, because it's not considered generally useful?</blockquote><div><br></div><div>Yes.  That's when you'll have the concrete context necessary to enable you to make the best implementation choice.  Until then, degrading code readability in exchange for no real-world performance benefit just... well, degrades the code...</div></div></div></div>