[Cuis] A few proposed is: additions

[Phil (list)]

Juan,

On Jun 15, 2012, at 7:05 AM, Juan Vuletich wrote:

> Hi Phil,
> 
> I agree with what you say, so I snipped those parts (especially #is* in compatibility package(s), that deserves a separate thread), to focus on the implementation.
> 

That makes sense... I'll think a bit more about the #is* options and start a new thread for that.

> Phil (list) wrote:
>> ...
>>> The problem is that to access the whole collection, including those from superclasses, you need to create collections on each call. This is too expensive.
>>>    
>> 
>> Sorry I wasn't explicit: I was assuming that there would be a cvar that got lazy loaded (including the walk up the hierarchy) by #protocols on the first call. From the second call on, the performance difference would just be a check for membership in the collection vs. the existing conditional logic approach.  A further assumption was that the class initialization logic would set the cvar to nil to ensure that there was a way to force its regeneration.
>> 
>> If you don't like the idea of creating per-override cvars, a centralized protocol dictionary (i.e. for classes with #is: overrides, the lookup would be performed and if it doesn't exist, populate it with what was returned from #protocols.) could be used instead.
>> 
>> A third approach could be to leave #is: alone and keep the introspection capabilities separate from the test, but then protocol information exists in at least two places: in the current #is: logic as well as the collection-backed store (whether via individual #protocols or a centralized store)
>> 
>> I think a fair question to ask is: does anyone else see value in what I'm proposing or is this something only I want?
>> 
>>  
>>>> 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).
>>>> 
>>>> ...
>>>>      
>>> Let's think of a better one, one that is fast and non- redundant.
>>>    
> 
> Well, your first proposal here is indeed fast (especially if we use #pointsTo:) and non-redundant. An issue is the need to call #initialize when the collection changes. It would be nice if this was automatic, somehow. Forgetting to do it could mean rather hard to find bugs. The first thing that comes to my mind is to have a well known message that gets sent to any class when a method is compiled. Let's see... (goes to look in Cuis...) Hehehe. It is already there: #noteCompilationOf:meta: . We can just use this method to clear the variable (btw, it shouldn't be a classVar but a classInstVar, right?) if the protocols change.
> 

So here I am spit-balling a general notion of how to do it and you get all specific about how to do it even better :-)  Of course you're right about class inst vars being the way to go.

> Besides, it looks a bit complex, but it seems to me that the value is greater than the complexity, so I'd go for it. Mhh. We'd also do some space analysis. I guess we'd be using just a couple of kb of RAM, so it's not an issue, but we should measure anyway.
> 

Since you've more than pointed me in the right direction, I went ahead and put together a test project to try to answer the memory and performance questions at https://github.com/pbella/Cuis-Experiments .  It implements parallel class hierarchies using the current #is: approach as well as one with the new approach we've been discussing.  Assuming my code is correct, performance varied from 4x faster (#is: checking multiple conditions) to 2.5x slower (simple #is: checks or the condition is matched quickly using the old method (i.e. without needing to walk the class hierarchy)) but you need a lot of iterations to even measure the difference on my machine at least.  Memory usage increased on the order of tens to a few hundred bytes per class (though I'm not sure how accurate the method I'm using is)  How does it look to you?

> Cheers,
> Juan Vuletich
> 
> _______________________________________________
> Cuis mailing list
> Cuis at jvuletich.org
> http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org

Thanks,
Phil