[ENH] ifNotEmptyCleans
stéphane ducasse
ducasse at iam.unibe.ch
Thu Sep 30 11:48:50 UTC 2004
I see the point.
Especially the fact that receiver is a collection make sense but this
is not consistent and not transparent.
I hate to have to read a method body to understand what is does because
we have abstraction but we break it.
Marcus for the
1 + 1.0 I is not at the same level because plus is overloaded and we
use that since we are kids.
When I read
ifNotEmpty:
I associate it with all the methods such as ifTrue:
ok this is a conditional and conditional do not take block arguments.
And now I have this particular method
that does it.....sure! and without any distinctive signs from its user
interface. Even better.
So I understand than for compatibility reasons we want to keep that but
at least:
- we should update the comment!!!!
- then be consistent with the other methods
>> For me I do not understand what it means to require an argument, in
>> this case this is not
>> ifNotEmpty: [do that]
>> but ifNotEmpty: [do that with self]
>> and the message does not tell that at all
>>
>> and why we have that for ifNotEmpty and not for ifTrue: and isNil:
>
> Because in the case of ifTrue: and ifNil: (as well as ifFalse:), if
> the block is evaluated then you know exactly what the receiver is, so
> there's no need to pass it in.
> This is also mostly true for #ifEmpty:, in that you know that you've
> got an empty collection, and that's probably all you care about. In
> the case of #ifNotNil: or #ifNotEmpty:, however, there are interesting
> things about the receiver (for #ifNotNil:, what the instance is, for
> #ifNotEmpty:, what instances it contains) that you *don't* know, and
> so passing the receiver into the block is very useful.
>
> I generally agree with you about the message names, in that I'd rather
> see ifNotEmptyDo: (to match #ifNotNilDo:) as a distinct method from
> #ifNotEmpty:. However, there's a compatibility issue here - other
> dialects expect #ifNotNil: and #ifNotEmpty: to take a 1-arg block, and
> we should probably follow suit. As it is I have to avoid using either
> message if I want my code to be portable, which is a shame.
>
> Avi
>
>
More information about the Squeak-dev
mailing list
|