Hi,
On Apr 28, 2016, at 2:29 PM, Denis Kudriashov <dionisiydk@gmail.com> wrote:
2016-04-28 11:07 GMT+02:00 Tudor Girba <tudor@tudorgirba.com>:
Put you logging api in a Trait instead of Object and let your MySpecialDomainObject use this trait ?
Really? Try remember usual workflow when we investigate some problems with code when we can't use debugger. We put kind of "Transcript show:" in multiple places to see state of our objects at concrete point of time. With object logging we will log our objects directly without converting to strings. Do you want to stop your "debugging workflow" every time you need to log objects which not support it? (to add special trait).
This is a totally different scenario than the one of logging for an unforeseen situation. For this purpose, in Beacon we have dedicated signals such as those that capture the stack or the context and we can imagine several more. It is more powerful than Transcript and requires no string. Furthermore, because we have the type signal, we can also easily have an inspector that shows the relevant information.
I hope you not think that I suggested to log strings. I never did it. I proposed to log domain objects instead of signals with ability to annotate them with additional information.
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. 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. 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."