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