Hi, On Monday 15 December 2014 12:21:23 Atgeirr Rasmussen wrote: > 15. des. 2014 kl. 12:50 skrev Joakim Hove <[email protected]>: > > - In my opinion, just renaming the current ParserLog class to OpmLog (or > > Opm::Log) is a not so smart idea, because this class' API is very much > > tailored to the parser module (what is the filename and the line number > > in a general purpose context? the source file location of the call? not > > really.) > > > > Well – the rename is certainly not sufficient; my idea was just to get > > that “out of the way” - and then the Log implementation could be changes > > silently in the Parser for some time without inducing downstream > > breakages – but your points are certainly valid. > I agree that such things as line numbers (of a deck in this case) may be a > bit specific, but there is no reason a general facility cannot support > this, especially with a few helper functions (for simple and consistent > message formatting for example).
I think you slightly misinterpreted me: A general logging facility is valuable
IMO, but its sole purpose should be to distribute the messages (each with a
priority) from any frontent to the delivery mechanisms (i.e., backends). The
frontends and the backends can be instances or singletons or whatever you
prefer...
> > Static message priorities make things like
> >
> > Opm::Warning << "foo!" ;
> >
> > easy. I cannot really see how this can be done using dynamic ones...
> >
> > I agree that Opm::Warning would be nice – but no that is not going to
> > play. Be it dynamic or static I really think the final filtering will be
> > based on a bitmask.
> I do not see why we cannot do someting like this (perhaps
> Opm::Logger::Warning() << "foo" will be better though).
>
> The use of Warning communicates the intent of the message sender, and the
> filtering will happen downstream in the process, when all connected
> backends are asked: "do you want to do something about a Warning message?"
> or something like that. They could even use a generalized polymorphic
> filtering mechanism as Andreas suggests (a good idea, but maybe also a bit
> of over-engineering at this point).
I agree on the over-engineering ;). The point was that this should be the
direction to look at because good software design should try to separate
mechanism ("backend") from policy ("filters")...
cheers
Andreas
--
the unix philosophy: do 90% of one thing, and barely do it adequately
-- Adam Jackson
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ Opm mailing list [email protected] http://www.opm-project.org/mailman/listinfo/opm
