Hey Igor is around \o/ BTW using size = 0 triggers a code critic telling you to use isEmpty.
Maybe there is a rule of isEmpty ifTrue: :-) I think that there could be a lot of convenience methods in the base image. They can be in an extension protocol, no issue. STON and gt have a ton of these. In the base image. About beginners, well: have a look in some Zinc code and learn a truckload of tricks. Like inject: somePath into: ... etc. And when puzzled, Halt now and debug or inspect it go a long way in figuring things out. As long as the method is intention revealing, what is the issue? At the risk of some flames, Pharo isn't bound to some Smalltalk compatibility. And that is what is cool about it. We chose another path now we have to go our way of else. Building on a great foundation is nice. But that doesn't equate to following the Smalltalk canon IMHO. And now 64 bits becoming real with a nice FFI and pinned objects... that is going to bring in a lot of non smalltalk stuff for sure. Phil Le 1 nov. 2016 15:14, "Igor Stasenko" <siguc...@gmail.com> a écrit : > > > On 1 November 2016 at 11:31, jtuc...@objektfabrik.de < > jtuc...@objektfabrik.de> wrote: > >> Phil, >> >> >> I see your point but disagree. >> I don't use Pharo regularly, so I cannot currently check if the >> implementation around this emptiness check is complete. >> >> With complete I mean that following your logic, theere should be at least >> implementations of >> >> ifEmpty: >> ifNotEmpty: >> ifEmpty:ifNotEmpty: >> ifEmptyOrNil: >> ifEmptyOrNil:otherwise: >> > > why pollution? > it just convenience method. mind you, that #isEmpty is also convenience > method, without it you would do it like: > > myArray size isZero ifTrue: [] > of wait.. #isZero also convenience method... so if you elitist then you > have to write it like that: > > myArray size = 0 ifTrue: [] > > And that , to my opinion, adds even more pollution to the user code, > because first, it is longer, and second > #ifEmpty: much better clarifies the intent of author, comparing to size = 0 > > >> I really have to check for the size of collections very often, and the >> size of 1 is a very frequent case. So why not add: >> >> ifExactlyOne: >> ifSizeIs:do: >> ifSizeIsGreaterThan:do:otherwiseDo: >> >> You get the picture. I strongly believe this leads to pollution and ends >> up in a mess. >> We could save so much typing and make our programs so much more readable >> if we only were a bit more creative, right? ;-) >> A DSL is another story, though. If you write a Library that makes >> handling Collections nicer, this is okay and the methods are good to exist >> in its context. But they shouldn't necessarily all be part of the base >> image. >> >> >> Don't get me wrong: if you and the Pharo community agree on lots of >> convenience methods, that is okay for me, and I find myself adding such >> methods to VA Smalltalk from time to time. I appreciate many of them being >> brought to VA ST in Grease. >> >> Sometimes, this is simply a question of taste, sometimes it saves typing, >> sometimes it helps to improve readability of code. >> >> But I wouldn't go so far to tell people they should better use such a >> method as a general advice. I would probably tell them: "look, here's a >> method I find much more elegant, you could *also* use that to save >> typing/increase readability". >> >> Just my 2 cents, and highly off topic ;-) >> >> Joachim >> >> >> >> >> Am 01.11.16 um 08:43 schrieb p...@highoctane.be: >> >> Because I grew tired of the isEmpty ifTrue: [ ] all over the place. >> And ifEmpty has the right semantics for my use cases (like assignment). >> >> I do not really care about portability, I am doing Pharo only. >> >> Phil >> >> On Mon, Oct 31, 2016 at 5:30 PM, jtuc...@objektfabrik.de < >> jtuc...@objektfabrik.de> wrote: >> >>> Am 31.10.16 um 15:59 schrieb p...@highoctane.be: >>> >>> but you should use myCollection ifEmpty: [ ... ] >>> >>> >>> interesting. Why do you think so? what if you wanted your code to be >>> portable across Smalltalk dialects? >>> >>> >>> >>>> >>>> >>>> >>> >>> >>> -- >>> ----------------------------------------------------------------------- >>> Objektfabrik Joachim Tuchel mailto:jtuc...@objektfabrik.de >>> <jtuc...@objektfabrik.de> >>> Fliederweg 1 http://www.objektfabrik.de >>> D-71640 Ludwigsburg http://joachimtuchel.wordpress.com >>> Telefon: +49 7141 56 10 86 0 Fax: +49 7141 56 10 86 1 >>> >>> >>> -- >> ----------------------------------------------------------------------- >> Objektfabrik Joachim Tuchel mailto:jtuc...@objektfabrik.de >> <jtuc...@objektfabrik.de> >> Fliederweg 1 http://www.objektfabrik.de >> D-71640 Ludwigsburg http://joachimtuchel.wordpress.com >> Telefon: +49 7141 56 10 86 0 Fax: +49 7141 56 10 86 1 >> >> >> > > > -- > Best regards, > Igor Stasenko. >
