[Cuis] A few proposed is: additions

[Juan Vuletich]

Mhhh. Been looking again at it. The problem are the references to 
#ShoutEnabled and #refusingToAccept. Answers to 'is: #ShoutEnabled' and 
'is: #refusingToAccept' are not static, in the sense that they depend on 
the state of the instance. This would suggest implementing 
#isShoutEnabled and #isRefusingToAccept. But as any object could be the 
ultimate model of a text morph, (thanks to PluggableTextModel) then 
#isShoutEnabled and #isRefusingToAccept would need to be implemented in 
Object, answering false. But neither of this messages make real sense in 
Object. Right now 'Object selectors size' is 190. This is less than in 
other Squeak variants, but it is still too much. Object should only 
include messages that make sense for any object. I think this needs more 
thought and discussion before integration...

Regards,
Juan Vuletich

Juan Vuletich wrote:
> Hi Phil,
>
> I apologize for taking so long to answer. I took a quick look at your 
> code, and I was hoping to integrate it before answering. But I haven't 
> done that yet, and I shouldn't delay any longer in answering.
>
> Thank you very much for your code. One thing you made me realize is 
> that there is at least one implementor of #is: (CodeProvider) whose 
> answer is not "static". This is incompatible with your idea of caching 
> the protocols in the class side. But I realized that it was an 
> improper use of #is:. That question should be #isRefusingToAccept, 
> with whatever needed implementors. So, please give me a little more 
> time to check the system and integrate your code.
>
> BTW, can I have your full name? Method #knownInitialsAndNames should 
> ideally include the name of all authors of code in the image. Anybody 
> else who want their initials / name in the image, please tell. 
> Besides, this is nice, because when the system needs your name, if 
> your initials are known, it tries to guess, and you can avoid typing 
> your name all the time.
>
> Cheers,
> Juan Vuletich
>
> Phil (list) wrote:
>> ...
>> 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?
>>
>>
>>   Thanks,
>> Phil
>> _______________________________________________
>> Cuis mailing list
>> Cuis at jvuletich.org
>> http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org
>>
>>   
>
>
> _______________________________________________
> Cuis mailing list
> Cuis at jvuletich.org
> http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org
>
>
> -----
> Se certifico que el correo no contiene virus.
> Comprobada por AVG - www.avg.es
> Version: 2012.0.2179 / Base de datos de virus: 2437/5097 - Fecha de la 
> version: 27/06/2012
>
>