I mentioned in another thread. #crLog, #logCr are intuitive and perfectly fine.
Also hook Loggers first class into the system ( Toothpick ) and make it default to Transcript with these messages routed to the Logger. Transcript cr / current #crLog is akin to cout / System.out.println .. mostly deprecated in enterprise coding practices. On Mon, May 6, 2013 at 3:04 AM, Sven Van Caekenberghe <s...@stfx.eu> wrote: > > On 05 May 2013, at 21:42, Stéphane Ducasse <stephane.duca...@inria.fr> > wrote: > > > Hi guys > > > > Stupidly I introduced log: a while ago to replace Transcript show:. Now > is the current situation. > > > > I still want to remove all the use of Transcript show: > > > > Now since I thought I did a mistake with log: because it overload > Integer>>log: I introduced trace: and traceCr: > > > > Now I do not like traceCr: because it is not a cool message. > > > > So what do we do: > > > > 1) we use crLog:, logCr: > > and deprecated log: > > > > > > 2) we use crTrace:, trace: and traceCr: > > > > I really prefer solution 1 but I would like to hear from you. > > > > Stef > > I am for 1 as well, but I find #crLog: or #logCr: confusing - there should > only be one system wide approach. > Also, whether or not to add a Cr to a log message (or before or after it) > is not a decision a client/user should have to make. > Maybe Cr makes no sense, for example when log messages are added to a > collection. > > So I am for #log: as a simple and clear message. > > The conflict with Number>>#log: is less important than that IMHO. > Either we live with the conflict or we rename Number>>#log: to > Number>>#logBase: or something like that. > > I also like the convention of #value being sent by #log: to its argument. > That allows for blocks that are not evaluated when logging is disabled. > > My 2c. > > Sven > > -- > Sven Van Caekenberghe > http://stfx.eu > Smalltalk is the Red Pill > > >
