On Thu, Jan 23, 2014 at 11:54 AM, Scott Deboy <[email protected]> wrote:
> We don't need to scuttle the new levels to support extensible levels. > Of course. The two things are not technically related. That's not what this is about, though. Since there are camps for and against the new levels, I was hoping the "extensible enum" feature would bring about a compromise. > > Gary's change is essentially a 'usability enhancement' - if anything > close to 80% of the folks who might want custom levels can use new > built-in levels, that's an API win in my book. Custom levels help the > other 20%, and I'm supportive of that. > > Also please keep in mind this doesn't really add to our maintenance > burden, which I think may be contributing to the concern about adding > new levels. Gary already did the heavy lifting, and the change to > something other than an enum for levels would just be a bit more work > because of this addition. > > Scott > > On 1/23/14, Paul Benedict <[email protected]> wrote: > > Let's not lose sight why the "extensible enum" discussion occurred. > > Speaking solely for myself, I am not fond of the new logging levels; but > I > > don't want the framework from preventing them. The intention behind this > > proposal was to get agreement by scuttling the new levels but allowing > > anyone to add them in their own private code. > > > > > Paul
