Hi Sven,
On Mon, Jun 16, 2014 at 11:54 AM, Sven Van Caekenberghe <[email protected]> wrote: > > On 16 Jun 2014, at 10:53, Tudor Girba <[email protected]> wrote: > > > - Like I said in my document and like I tried to show in my > implementation for Zinc, I want framework agnostic pure object logging, so > I don't want to subclass from anything (I do from Announcement, but that is > an implementation detail, the technique how #emit is done), can you deal > with the ZnNewLogEvents as the are ? > > > > As you can see at the end of the post, you can just use your own > Announcements. There is no real magic there. So, it should be no technical > problem to accommodate the logging of ZincEvents as they are. > > Yes, but even being an Announcement subclass is debatable. If you can announce any object, then you do not need Announcements either :). > > However, one thing that we should also think about is the actual > analyses that we might want to do. For example, the inspector extension for > RecordingBeacon uses: > > - timestamp, and > > - printOneLineContentsOn: > > > > And these requirements will grow even more as we are building more > specialized tools. So, to this end, it is useful to have some common ground. > > Yes, I mentioned this already several times: traits listing expected > protocol would be good. Maximum polymorphism, latest possible binding, no > dependencies, composable. Agreed. All I said is that to find the useful protocols we need to build the tools and not stop the discussion at the recording part of the logging. > > Now, as far as I know, the only reason why you do not want to subclass > BeaconSignal is because you want to use ZnTimestamp. I see no reason to > have two Timestamps in the image anyway, so I have no problem pushing just > one. > > Or do you have another reason? > > I first of all want no dependency so that different logging backends can > be plugged in or used. I think that this takes away any lock-in anxiety > from people like myself, which will increase adoption. > I do not understand that. First, we talk about a handful of lines of code. Second, actually your newest implementation already ships a more specialized version of Beacon, so from this perspective Zinc already binds me at least to Announcements. Is this a bad thing? I think it is rather pragmatic. > BTW, it is ZTimestamp not ZnTimestamp, it has absolutely nothing to do > with Zinc. ZTimestamp is second precision, UTC only, and takes half the > size. It comes with cool formatting/parsing, full timezone and basic SNTP > support. > Yeah, my bad. > No, I want all users to be able to make there own choices for whatever > reason (efficiency, precision, portability). The timestamp is the only > concrete element we can discuss now, but there could be others. > Freedom is good in the sense that people should be able to customize anything they want. At the same time if you want to provide services on top, you need to find a useful commonality. In our concrete case, I see no reason to keep DateAndTime when the other one is better. Doru -- www.tudorgirba.com "Every thing has its own flow"
