SystemNavigation and deprecated methods

Daniel Vainsencher danielv at netvision.net.il
Tue Aug 12 08:22:44 UTC 2003


I agree that some methods could proably be class extensions, and Stef,
this is quite trivial to do, just put the method in a category called
"*system-support", and you're done. Easy as drag and drop.

Andreas, lets be specific, what selectors would you undeprecate and 
move back to Class and its friends?

Somehow it seems natural to me (as a user, not from any SE point of
view) to invoke a tool, rather than the model object, if I am expecting
a UI, so I might be inclined to keep the browse* methods in SysNav. 
>From an SE POV, the non-GUI methods (such as #allCallsOn:), while 
implemented on the classes, could be made class extensions.

On the new/default/global issue - at some point the KCP said that 
making SysNavs behavior class side is bad. Now you're saying that 
Globals are bad (or as Andreas notes, that non-class globals are bad). 
Unless you want Squrak to lose its conciseness, something has to 
give. And conciseness in programming languages is power.

I can personally live with SystemNavigation default, but every time 
I write that name I find myself looking for a shortcut.... How about 
the global CodeOracle? (mostly kidding :-)

Daniel

Stephane Ducasse <ducasse at iam.unibe.ch> 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