Hi, On Monday 15 December 2014 11:50:31 Joakim Hove wrote: > - Why does the ParserLog class need to be renamed at all? I'd rather see it > to be a frontend for the Opm::Log class which itself can be a singleton > that acts as a plumbing layer between frontends and backends > > > > A instance based frontend to the singleton?!
yep, why not? I suppose that other "singleton like" objects like std::cout do
get use a lot by instantiated objects...
> - wouldn't it be better to wait until the Big Module Hierarchy Refactoring
>
> (TM) is done so that the parser module does not need to host such general-
> purpose infrastructure code? I mean, the dependencies between the modules
> are already confusing enough as they are...
>
>
>
> Well moving the log class out of the Parser/ subdirectory was in preparation
> for the "Big Module Hierarchy Refactoring" (BMHR). It should be absolutely
> trivial to rip the log implementation out of opm-parser and into opm-xxx.
true. the point was more that this confuses things until the refactoring has
been started. (a period which I hope includes a release just before the
refactoring frenzy...)
> 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.
yeah, but if I don't see things more complicated than strictly required,
"dynamic log levels" and "bitmask" are mutually exclusive. to me, "dynamic
logging" means to use something like "std::set<LogLevelSpecifier>"...
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
