SystemNavigation and deprecated methods

Stephane Ducasse ducasse at iam.unibe.ch
Tue Aug 12 07:00:21 UTC 2003


A final point.
We have no problem to change however we asked during weeks for people 
to review what we did.

Stef



On Tuesday, August 12, 2003, at 08:55 AM, Stephane Ducasse wrote:

> Hi andreas
>
> On Tuesday, August 12, 2003, at 01:18 AM, Andreas Raab wrote:
>
>> Hi Guys,
>>
>> I was just browsing over all the senders of #deprecatedExplanation: 
>> to see
>> what kind of things have changed and there were a few oddities that I
>> noticed.
>>
>> First of all, given that SystemNavigation is stateless, wouldn't it 
>> make a
>> lot of sense to have a global called "SystemNavigator" or somesuch 
>> which you
>> can send the appropriate queries to? E.g., it's somehow terribly
>> inconvenient having to write "SystemNavigation new doSomething"
>> (SystemNavigation>>uniqueInstance or SystemNavigation>>default are no
>> better). It seems to me that having this global is really not taking 
>> away
>> anything but makes the functionality of SystemNavigation readily and
>> conveniently available.
>
> I agree (and I already asked for feedback on the topic) that 
> SystemNavigation new doSomething
> is bad. Then having a global variable is not good for several reasons: 
> (1) we do not have that good tools to check their definition, 
> state...(don't tell me that we have inspector) I can browse really 
> easily with my stupid browser all the classes but global are always a 
> bit magic (2) in a OO model we do not need global as we already have 
> classes, so if we could slowly get rid of global this would be better. 
> I think that SystemNavigation>>default is quite good. Can you tell us 
> more what you do not like it.
>
>> Secondly, some of the deprecated methods I think shouldn't be 
>> deprecated at
>> all - most importantly those that refer to finding references to some 
>> symbol
>> in the scope of some class. If I want to know something about a 
>> specific
>> class (such as if it sends a selector, reads or writes a variable) it 
>> seems
>> very natural to me to ask that class about it rather than some third 
>> party
>> (which has a very intrusive, non-OO feel; just like poking around 
>> blindly;
>> really what does SystemNavigation know about B3DHardwareEngine?). It 
>> seems
>> to me that most of the methods involved here really ought to be 
>> extension
>> methods provided by SystemNavigation.
>
> I did not have a deep look but the reason where:
> 	- There was a lot of duplication between SystemDictionary and 
> ClassDescription Behavior
> 	(nathanael was really mad about that when he implemented the first 
> version of traits).
>
> 	- There were a lot of dependencies from PopUpMenu and other UI in the 
> core of the system
>
> 	- A final important point: Note that the majority of the navigation 
> method in ClassDescription
> 	or other were mainly utilities method querying SystemDictionary 
> (Smalltalk directly).
>
> 	- I agree that we can think that asking the SystemNavigation about 
> references in a class
> 	can be perceived as not completely OO. We had the idea that the core 
> should be minimal, and with
> 	the context of the three other cases it pushed us that way.
>
> 	- Now we are not saying that we are right on all the stuff we do. We 
> had a lot of discussions, analysis, pros and cons,
> The most difficult one was method calling "class 
> whichSelectorsReferTo:" has the information use by the method is 
> really accessing the bytecode.
>
> So if you have some precise points just raise them and we can fix 
> that. It would be good before 3.6. Now you now the consideration we 
> took into account. For me ideally I would like to work in the context 
> of a packaging system because lot of stuff could be moved in class 
> extensions: keeping the kernel small and still providing the feeling 
> of having a good (sometimes bloated) OO system.
>
> For example I would like to have SystemNavigation default and not this 
> ugly SystemNavigation new
>
>
>
> Stef
>
> 	
>
>
>
>
>>
>> Thoughts?
>>
>> Cheers,
>>   - Andreas
>>
>>
>>
>



More information about the Squeak-dev mailing list