[Cuis] A few proposed is: additions

[Phil (list)]

Juan,

On Jun 12, 2012, at 7:30 AM, Juan Vuletich wrote:

>> 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).

Several of the packages I've ported used the old is* methods for type checking which I've either had to remove or replace with brittle class checks for now.  In addition, much of the code I'm writing would benefit from them as well.  There are two main situations that come to mind: the first being in-image behavior checking/documentation where type doesn't matter and the second is crossing the image boundary (FFI, emitting text/data files of a specific spec, etc.) where type is everything.  In both scenarios,  the intention is to have errors occur closer to the true source of the problem or ideally preventing the problem from occurring in the first place by noticing that a setter is performing an inbound check.  The second case being more useful when working with code written by someone else.

For example, some of the text/data processing I'm doing will result in the debugger effectively popping up in the middle of nowhere from a code standpoint because it really needed some kind of a date but was passed a string (or some other object behavior mismatch) at some point well before the code actually failed rather than when it finally needed that date behavior.  Iterating over a number is another fun scenario... tracing back to how that number got there isn't always easy as it may have been 25 steps ago in the 10th data file read etc.  Sometimes this is the result of bad data, sometimes it's me simply forgetting to parse/convert good data.

> 
>> 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).
> 

I have two in mind:

1) When thinking about overriding is:, it would be useful to be able to look at the other protocols defined to remain consistent where it makes sense (both in terms of defining a new protocol or re-using one that already exists).  Currently you'd have to browse all implementers of is: to do so.  Not a big deal when the number of is: overrides is small, but it becomes unwieldy fast.

2) When code breaks and you land in the debugger, it would be nice to have a quick way to answer the question 'what is this object it's having a problem with?' in a more abstract sense than what is its class.  Same issue re: browsing implementers of is: as there may be more than one override in the class hierarchy (i.e. if #Number were defined at the top of the hierarchy and #Float were defined further down in the case of numbers.).  This, matched with appropriate is: checks would make troubleshooting some problems much simpler.  Obviously, more classes need to override is: before this use case could be realized.

I guess how I'd envisioned it working is: would just become the test method and would call a class side protocols method that would actually return the collection of protocols that a given class supports.  Then in the debugger/workspace you'd call foo class protocols.

If there's a better way to accomplish either what I'm looking for in my first answer or what I'm proposing here I'm open to it, this is just what I've come up with (likely without considering other valid scenarios or issues).

>>> 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!


True for me as well.

Thanks,
Phil