2010/3/3 Nicolas Cellier <[email protected]>: > 2010/3/3 Stéphane Ducasse <[email protected]>: >> >> On Mar 3, 2010, at 1:28 PM, Henrik Johansen wrote: >> >>> >>> >>> Den 03.03.2010 10:36, skrev Stéphane Ducasse: >>>> Browser vs SystemNavigation and much more such as abstraction (traits kind >>>> of mistakes) for the sake of it. >>>> >>>> I was thinking that I would love to have a message-oriented solution. >>>> One of these days 1.2 we will have to clean Smalltalk, SmalltalkImage >>>> current. >>>> The mail is long but worth to get some ideas that you may like or not. >>>> >>>> Stef >>>> >>> I have to say I support what to me seemed like the general consensus on >>> this, that the separation just didn't go far enough to make it worth it :) >>> I especially like the >>> Smalltalk vm parameterAt: >>> Smalltalk query allCallsOn: >>> etc. >>> protocol, sure you add a globals category to SystemDictionary, but to me >>> the resulting code looks much better than both the current state of >>> SmalltalkImage vmParameterAt: and SystemNavigation current allCallsOn: >>> (or were those class methods?), and the old where SystemDictionary was a >>> complete mess. >> >> I agree with part of it (see my next/previous mail :) >> >> even if for SystemNavigation I do not really like Smalltalk query ccalll.... >> > > My own position is this one: > > 1) Rename Browser -> SystemBrowser > 2) Rename SystemNavigation -> Browser > 3) move SystemNavigation methods -> class side > > Rationale: > 1) that's what is written in window title, isn't it ? > 2) Browser allCallsOn: and Browser browseAllCallsOn: are so neat ! > 3) Is there any value in instance side, or is SystemNavigation just a factory > ? > > Browser would not designate the tool, but the friendly compagnon used > to browse and query. > You can easily create a few compatibility hooks to SystemBrowser if required. > > Nicolas >
Of course, unless SystemNavigation become a statefull object remembering navigation paths, caching frequent requests etc... In which case, it wouldcease to be a factory. >>> The important thing if this becomes the solution, is deciding what goes >>> where, (in a consistent fashion across forks), >> >> I'm sure that we will be able to have something that is cross fork. I do not >> have the energy >> to argue. >> >>> as well as the level of >>> backwards-compatibility packages should be offered/deprecation methods >>> kept in the image. >> >> _______________________________________________ >> Pharo-project mailing list >> [email protected] >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > _______________________________________________ Pharo-project mailing list [email protected] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
