No, I did not suggest that you want to log strings. I simply said that this type of use case is different than the regular logging use case. I think it is important to treat these two separately because indeed when you debug you are in a prototyping mode and you want to go fast. In this situation, you do not want to have to create a separate class. But, for the long term logging you have different requirements and there you want to be more rigorous, and in that scenario creating a new class is acceptable. If we design a logging infrastructure the second use case is what we want to optimize around.
Indeed Logging is not just about replace Transcript show:
Of course, we should still think about the prototyping part. I found that it is often more interesting to log entire contexts (and have a post-mortem debugger) than individual objects. Nevertheless, with something as simple as:
object asBeaconSignal log.
It worked fine.
And if I really wanted to add extra information, I rudimentary did:
{âsome textâ . object } asBeaconSignal log.
Or even:
{âsome textâ . #someSymbol . 42 . object } asBeaconSignal log.
I got a similar but not based on array but with a block to handle extension without subclasses.
It is not the most elegant solution, but it is very malleable and good enough for debugging purposes. If we would have instance-based filtering for announcements, we could filter based on that without any extra effort. Also, if we would have a composition mechanism in place, we could build these objects with a more elegant API.
Regarding your statement of logging domain objects, you will have to store these objects with the additional information somewhere, and that will be a wrapper class. I do not see the difference with the Signal.
Cheers, Doru
-- www.tudorgirba.com www.feenk.com
"We can create beautiful models in a vacuum. But, to get them effective we have to deal with the inconvenience of reality."