#ifEmpty: and its brethren
Julian Fitzell
julian at beta4.com
Mon Dec 1 18:18:53 UTC 2003
Back in September, Ned submitted an ENH with some methods that are used
by the RB. One set of methods were the #ifEmpty/#ifNotEmpty:
variations. After some discussion, it seemed there was consensus to add
these methods in forms that take 0-arg blocks as arguments (original
message quoted below).
Does this need to get posted as a new, separate ENH? I tried to check
if it had already been put into 3.7a, but the 3.7a images are
segfaulting my VM and I don't have time to figure out building a new one
atm.
I don't mind making and posting the changeset if desired, though because
of the above I can't test it in the latest 3.7 right now.
Julian
Some time ago, Andreas wrote:
> Hi Daniel,
>
>> > -1: SharedPool deliberately doesn't use dictionary
>> >protocols.
>> Well ok, but -
>> A. RB needs to know whether the bindings includes: name.
>> B. In 3.6 some pools are dictionaries.
>
> I understand this. The point was that we should think hard about which
> protocols _do_ make sense for shared pools and for which ones we should make
> up new ones. I'm not decided on #keys by the way - most of the trouble is
> modifying pools and keys happens to be an inquiry. So I could live with
> that.
>
>> > > 4. Collection>>ifEmpty:ifNotEmpty: and variations.
>> > -1: This should not be sneaked in as a "small change" given that it
>> > significantly extends the collection protocol.
>> Well, you caught me. Let the arguments begin :_)
>>
>> > And is questionable in the
>> > semantics - the asymmetry between #ifEmpty: (0-arg block)
>> > and #ifNotEmpty: (1-arg block) greatly disturbs me.
>> Ok. I can go for 0-arg #ifNotEmpty:. Then we're ok? anybody else have
>> strong feeling either way?
>
> I'd be happy with any symmetric solution.
>
> Cheers,
> - Andreas
More information about the Squeak-dev
mailing list
|