>
> On a serious note, libary methods, like that method, ought to be fast,
>>>
>>
>> Every method in the image is a library method, so what do you mean by
>>
>
> Really? Explain me how Browser >> #defaultBrowserTitle, a method I chose
> randomly, is a library method?
>

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?


>>
> ....


>
>
>> because you can't know in what situation they will be used. Saying that
>>> it's
>>> not even used is therefore not a valid reason.
>>>
>>
>> That's only true for the very lowest-level methods.  Generally, it's
>> better to design and code for what's known, and NOT try to code for
>> the future / unknown.  IF and when that future comes, it'd be easy
>> enough for you to deal with any performance issues at THAT time.  In
>> the meantime, we "ought"  :) to keep as much beautiful minimal
>> elegance as we can.
>>
>
> 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?


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...
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20180503/4225cc9a/attachment.html>