On 1 November 2016 at 17:00, phil@highoctane.be <phil@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" <siguctua@gmail.com> a écrit :
On 1 November 2016 at 11:31, jtuchel@objektfabrik.de < jtuchel@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 phil@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, jtuchel@objektfabrik.de < jtuchel@objektfabrik.de> wrote:
Am 31.10.16 um 15:59 schrieb phil@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:jtuchel@objektfabrik.de <jtuchel@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:jtuchel@objektfabrik.de <jtuchel@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.