[Cuis] A few proposed is: additions

[Phil (list)]

Juan,

On Jun 27, 2012, at 10:17 PM, Juan Vuletich wrote:

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

Perfect timing :-)  I figured you either needed more time to think it through or were busy on other things so I took a shot at integrating it into the image to see what I ran into (I have a changeset that I'll finish up and publish to github tomorrow) and here's what I found:

1) As you mentioned: CodeProvider and PluggableTextModel.  For CodeProvider, isn't that just performing static tests on two symbols? If so, the approach proposed can handle that without a problem.  For PluggableTextModel, I overrode the #is: method for it and added the dynamic test before the static test. (before vs. after was just an arbitrary call on my part) thinking that this could be documented in a couple of places via method comments.  As the dynamic check is calling #is: on whatever the inst var in question happens to be, I didn't think too much of it at the time... do you anticipate this being a more common scenario going forward?

How about adding a #protocols entry of #dynamic to indicate that a particular class is performing an (at least partially) dynamic #is: check?  The result would seem to be that #protocols would still correctly identify all valid protocols, the #dynamic entry would identify cases where the determination isn't entirely static, and #is: (via the override described above) would behave identically to the current implementation.

2) Given the warnings in Object re: not adding inst vars due to VM assumptions and recent list discussions re: VM changes, I was concerned that about an issue that may or may not be valid.  Even though class inst vars weren't mentioned specifically, adding one on Object might be a bad idea as there could be unanticipated consequences (now or in the future).  The workaround I came up with was to put the class inst var in the direct subclasses of Object that implement #protocols rather than Object itself.  This required some minor logic changes (including a new method #protocolsReset that just sets the class inst var to nil) and results in some code redundancy which could possibly be (at least partially) avoided via dynamic introspection but I haven't dug too deeply into this yet.  This results in a less clean / simple implementation but was the best I could come up with given what appear to be the realities of the VM.

I was actually more concerned about second item than the first... your thoughts?

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

Sure: Phil Bellalouna and my code uses pb as initials.

>> Cheers,
>> Juan Vuletich


Thanks,
Phil