15. des. 2014 kl. 12:50 skrev Joakim Hove <[email protected]>: > I guess it's my turn to give two and a half cents of worthless opinions: > > All opinions are welcome! >
Indeed, and your points are valid. > > - 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). > > 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). Atgeirr _______________________________________________ Opm mailing list [email protected] http://www.opm-project.org/mailman/listinfo/opm
