[ANSI-Smalltalk] Re: A list of interesting methods, ifNotNil:

[Richard A. O'Keefe]

On 4 Sep 2008, at 5:36 pm, Paolo Bonzini wrote:
> The standard can force implementation to support both cases.  That's
> slowly becoming the standard.

Agreed, although bi-arity isn't really to my taste.
>

> I think Squeak has ifEmpty:ifNotEmpty: but I agree that...

Collection>>
    ifEmpty: niladicBlock
    ifEmpty: niladicBlock ifNotEmpty: eitherAdicBlock
    ifEmpty: niladicBlock ifNotEmptyDo: monadicBlock
    ifNotEmpty: eitherAdicBlock
    ifNotEmpty: eitherAdicBlock ifEmpty: niladicBlock
    ifNotEmptyDo: monadicBlock
    ifNotEmptyDo: monadicBlock ifEmpty: niladicBlock

All of these methods are of course trivial.

One issue with the interface is that in the "ifNil"
case it makes sense NOT to pass the receiver to the
ifNil block because there is only one possible value
that the ifNil block could be concerned with and it
always has a name (nil).  However, in the case of
ifEmpty, there are very many empty collections, and
if there was always a name for the receiver, there
wouldn't be any point in accepting either arity for
the notEmpty case.  There appears, in short, to be
no good reason for not having ifEmptyDo: and for
not making ifEmpty: accept a monadicBlock as well
as a niladicBlock.

What I'm really concerned about is things like the
DateAndTime class, where the ANSI specification
appears to be unimplementable.  There are two
conflicting requirements: we must be able to do
arithmetic on these timestamps, and they must be
in UTC. This requires the ability to predict leap
seconds for hundreds of years in advance...