On 1 November 2016 at 17:00, p...@highoctane.be <p...@highoctane.be> wrote:
> Hey Igor is around \o/ > Hey heya! :) > 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 > > well, if continue on that, i think that while #ifEmpty: is perfectly fine, the #ifEmptyOrNil: are not. And indeed, in this case im also inclined to see those as pollution. Because uninitialized state can (or better to say - *must*) happen in one form - either it is nil, or empty collection, but not both. If your code having entry points that treats both of those as some kind of uninitialized state, then i would call it bad. To my opinion, it is bad practice to declare 'my method(s) can deal with any shit you can throw into it'. Personally, i prefer to clearly state what it accepting and what not, and strongly discourage any other free-form inputs, or even better - making them impossible to appear, so you don't have to put #ifEmptyOrNilOrCrazy: everywhere to make your code idioto-proof :) And the stupidity-proofing is quite simple, use converters/validators immediately on passed external data: myMethod: externalData myValidState := externalData asSanelyCheckedData. so, like that you don't have to put: myValidState ifValidState: [] everywhere :) 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. >> > -- Best regards, Igor Stasenko.
