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.