Am 16.06.2014 um 12:10 schrieb Tudor Girba <[email protected]>: > 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 :).
I agree with Sven here. I think the need to subclass another framework class is a big restriction. Announcements (as any object) have static part (class, instVars) and a dynamic part. In this case it is the infrastructure and the way they get delivered, the way I can register for receiving them etc. To me the latter is the important part. I never understood why not every object can be an announcement. This way it just leads to doubled class hierarchies just for the sake to announce anything. Norbert > > > > 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"
