[Pharo-project] Transcript rant

Stéphane Ducasse stephane.ducasse at inria.fr
Mon Apr 4 17:23:23 CEST 2011


> Yes. Consider and API of well established unix logging facility such as syslog.
> From application's point of view there is only one direction in
> communication: it writes to syslog, and syslog then directs content
> somewhere else (and where exactly is doesn't matters and not a concern
> of application).
> And its also thread safe, of course (but not at cost of having only
> single way to do things). And apparently there is no API to read what
> is just written (like #ensureCr, which implies reading the last
> character from stream to check if it is cr).
> 
> In this respect an old implementation was much nicer in a sense that
> it could be replaced by different stream which responds to same
> protocol..
> But now, Transcript is a class, and its much harder to replace it and
> as to me it is too hardwired.
> Maybe this is good for Cuis, but as to me, i consider Transcript as a
> generic/default logging facility in smalltalk system.
> I was planning to redirect Transcript to write to stdout when in
> headless mode (and when VMs will provide stdio communication out of
> the box).

Yes we are in sync on that.

> But how i suppose to do it now? Hacking existing class? And then
> again, what if someone wants to redirect transcript to socket (and its
> easy to imagine where we may need that - suppose you working with
> remote image and want to see its transcript).
> So, hacking the same class again?


Ok so how do we make progress?

> P.S. i know that maybe a preferable way to do logging is through 'self
> log:' protocol etc..
> but lets face reality: there are a tons of code in system which using
> Transcript.  And i don't think that we will abandon it in nearest
> future.
> So, lets just keep it and make it more nicer, but lets separate concerns.




More information about the Pharo-project mailing list