I guess it's my turn to give two and a half cents of worthless opinions:
All opinions are welcome! - 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. - Dynamic log levels can be done, but I think if they only add a tiny bit of API-level inconvenience compared to static log levels, I think they are not worth it. The concept of dynamic log levels is meeting "some resistance" - so I guess that might at the very least start out on the backburner. - 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?! - 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. 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. >That should probably better be the job of "filters" which could be simple >classes which exhibit an method OK - filtering; that was sort of where I put the abstraction limit - thinking that log backends would handle that decision themselves. Jaokim ------------------------------------------------------------------- The information contained in this message may be CONFIDENTIAL and is intended for the addressee only. Any unauthorised use, dissemination of the information or copying of this message is prohibited. If you are not the addressee, please notify the sender immediately by return e-mail and delete this message. Thank you
_______________________________________________ Opm mailing list [email protected] http://www.opm-project.org/mailman/listinfo/opm
