[Cuis] A few proposed is: additions

[Juan Vuletich]

Hi Phil,

Phil (list) wrote:
> Juan,
>
> On Jun 8, 2012, at 7:41 AM, Juan Vuletich wrote:
>
>   
>> Hi Phil,
>>
>> At first, when I coded the #is: methods I thought about using them everywhere. But when the sender is really concerned about performance, #is: might be too slow. The old #isXX with a hardcoded answer is faster. You can check a bit the senders for #isBoolean, #isString, #isCharacter, etc. So, I don't have anything about implementing it in the classes you say, but please add a comment in the implementation in Object and in those subclasses where the older #isXX is still there, to explain the reason for having both.
>>
>>     
>
> Good point re: the performance concern.  I hadn't thought about that but will keep it in mind as it could potentially be an issue for something that might get called very frequently like is: #Character.  I wasn't clear if the plan was to completely do away with is* in favor of is: or not so your clarification helps.  So my followup question becomes: for something that is likely to be frequently called like #isCharacter that has previously been removed would you prefer to add it back in or replace it with is:?  

It just depends on what you need. What do you need it for? (if you don't 
then just don't add it).

> Also, for cases where is: does make sense, have you considered rather than hard coding them, backing them up with a collection so that something along the lines of Smalltalk allProtocols could be implemented or is that also a performance concern?
>   

I never thought about that. Do you have an use case in mind? (I usually 
avoid implementing stuff until I have a good reason. Having a use case 
usually helps doing a better implementation).

>> BTW, several times somebody asked some good question like this one, that I knew the answer, but hadn't thought about a clarifying comment. This is the moment to add it!
>>
>> Cheers,
>> Juan Vuletich
>>
>>     
>
> That's part of why I'm asking some of these questions rather than just assuming/doing.  I figure since we now have the mailing list, let's take advantage of it to help document why things are the way they are as it will hopefully help us work in a coordinated manner.  Plus, I'm really lazy and would prefer not to make a bunch of changes that don't make sense :-)
>
> Thanks,
> Phil
>   

You'd see how much of the code I write, I end discarding. Not a bad 
thing to me!

Cheers,
Juan Vuletich