> On 22 Jan 2020, at 13:10, Gabriel Cotelli <g.cote...@gmail.com> wrote: > > 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.
this is my point. > 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. Indeed now we found cool to be able to do it. But what is the cost because nothing prevent you to have your own vocabulary. This is what RBCondition is doing for example. > 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 <steph...@netcourrier.com > <mailto:steph...@netcourrier.com>> wrote: > > >> On 21 Jan 2020, at 23:46, Esteban Maringolo <emaring...@gmail.com >> <mailto:emaring...@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 <s...@clipperadams.com >> <mailto:s...@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 >> <http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html> >> >
