On Jan 22, 2020, at 5:20 AM, Benoit St-Jean via Pharo-dev
<[email protected]> wrote:
>
> Who, in their right mind, would code like that? Is it a trend among younger
> Smalltalkers while dinosaurs like me just "naturally" still use the "old way"
> and blocks?
Using symbols for blocks has been around for quite some time. I heard about it
from Ward Cunningham about 25 years ago. Early Smalltalk images were limited by
the number of objects that could exist. If you used a block, then you needed to
create an object for that block, but if you used a symbol, you didn’t need any
additional objects as the symbol already existed. When I heard about this, I
didn’t know of any Smalltalk’s that implemented Symbol>>value: in their base
classes. I think it was a couple years later before I started seeing it used.
As for whether Symbol>>value: should exist in the base Pharo image, I don’t
have a strong opinion. There are a bunch of methods/classes that could be
removed from the base image and put into add-on packages. As for whether Pharo
should allow someone to create such a method, I think it should. It really
isn’t any different from allowing me to add any method to any other class. As
for the readability of the code, once you know the symbol as block “trick”, I
find that they are both almost equally readable. In fact, the symbol version
may be a little more readable as when you scan the block, you must check the
receiver is “each” and not something else like “self” (which is the same length
as “each”). Finally, as for making a type inferencer more complex, dealing with
dynamically typed Smalltalk is already a complex job so if you can handle it
without symbol blocks, I doubt that it would take much more to add support for
them.
BTW, there are other objects that implement #value:, and can be used instead of
blocks. For example, to get a collection of the first 256 characters:
(0 to: 255) collect: Character
John Brant
