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
|