Hi!

I see no problem in replacing the symbol usage with blocks. It's a nice shortcut for scripting but not a game changer.

And I'm also in favor of being cautious before introducing new things without analyzing it's impact.

However, I see use cases for using objects polymorphic with blocks. A common case is to use some reification for a condition instead of a block evaluating to true/false. We have many of this in our systems where the end user needs to filter some kind of collection, and the filtering options are based on some other objects that the user creates in the system, and the user also wants to save his filter configuration so the next login this options are preserved. If you try to use blocks to model this conditions is more complex than using a proper abstraction, and more if you end up needing to persist this preferences in a relational database.

I don't know how this kind of scenario impacts the analyzer but for sure it has to cope with the reality that the people will be using things polymorphic with blocks. And if the analysis is static sometimes the object will be a block, but will come in an argument of the method and you don't know that doing static analysis.

On Wed, Jan 22, 2020 at 5:09 AM ducasse <stepharo@netcourrier.com> wrote:

On 21 Jan 2020, at 23:46, Esteban Maringolo <emaringolo@gmail.com> wrote:

I also like the polymorphism of the #value: message, not only with Symbols but also with MADescriptions and many other uses.

Thanks this is exactly my point and I do not like it because this is cheap and put the hell on tools.��
Of course the alternative is a bit more verbose because if you want to have��

aCol��do: MADescription new

then��
you would have to have��

myDomain >> do: anObject

��. ��. anObject value: ��.

But this means that a type inferencer could see that your code is calling this domain >> do: with a MADescription

Now we destroy all the knowledge because do: has as argument anything on earth.
What a gain.��
We went from

any��do: argument is a block and your do: has a MA��

to any do: implementation can get any object.��

So forget do build nice tools.��

After we can all program with perform: everywhere, but the trade we make is lame.��

Symbol >> value: anObject��
^anObject perform: self.

I have no problem that libraries break the possibility to have better tools applied to them.��
To me having value in Object is bad.��

I��m fed up of our attitude.
We are lame because we do not look further than our little nose.��

S.��

If that feds you up, and others too, maybe that "convention" (to use blocks only) might be scoped to Pharo core (whatever that is) methods.

Regards,

El mar., 21 de enero de 2020 19:35, Sean P. DeNigris <sean@clipperadams.com> escribi��:
ducasse wrote
> in Pharo we should write��
>�� aCol do: [ :each | each store ]

I always enjoyed the Symbol/Block polymorphism because I thought it was such
a clever and visible example of the power of Smalltalk, and, let's face it,
I'm lazy and enjoyed saving a few key strokes!

That said, I had no idea that there was a dramatic performance cost. Also,
the issues you raise about analysis seem important.

Since people are free to still use it in their own projects, it doesn't seem
to controversial. Can/should we add a lint rule? Can/should it be scoped to
Pharo core?

-----
Cheers,
Sean
--
Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html