deno_std
deno_std copied to clipboard
deprecation(log): deprecate `LogRecord` class and use plain object instead
Is your feature request related to a problem? Please describe.
LogRecord
is a class with only properties and getters. It seems the same can be achieved with plain js object.
Describe the solution you'd like
Deprecate the LogRecord
class and export LogRecord
an interface instead. Replace all new LogRecord()
occurrences with a plain object.
export interface LogRecord {
msg: string;
args: unknown[];
datetime: Date;
level: number;
levelName: string;
loggerName: string;
}
Describe alternatives you've considered
Leave as is.
I'm for this. Having a plainer/simpler symbol that achieves the same functionality is a good idea.
I just wonder how to introduce this without a breaking change. Should we just deprecate the class and introduce the interface after the class removal?
I'm not sure there is a way to make a non-breaking change either. However, the change seems easy-to-make, from the user's perspective, and is a small dump in design simplicity. Any thoughts, @kt3k?
Before:
...
fileHandler.handle(
new LogRecord({
msg: "AAA",
args: [],
level: LogLevels.ERROR,
loggerName: "default",
}),
);
...
After:
...
fileHandler.handle({
msg: "AAA",
args: [],
level: LogLevels.ERROR,
loggerName: "default",
});
@kt3k, would you be in favour of doing this in v1?
I don't understand the motivation. It doesn't seem solving any problem.
the same can be achieved with plain js object
I think this assumption is not strictly correct. The getter-only fields are currently immutable, but if we change it to plain object, they become mutable (readonly
works for TypeScript, but it doesn't work for JavaScript).
I don't understand the motivation. It doesn't seem solving any problem.
the same can be achieved with plain js object
I think this assumption is not strictly correct. The getter-only fields are currently immutable, but if we change it to plain object, they become mutable (
readonly
works for TypeScript, but it doesn't work for JavaScript).
That is true, but these properties have getters because the values are objects. So in the spirit of that whole class with getters and readonly properties, the object could just as well be frozen.