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