deprecation(log): deprecate `LogRecord` class and use plain object instead about deno_std

[iuioiua]

I'm for this. Having a plainer/simpler symbol that achieves the same functionality is a good idea.

[timreichen]

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?

[iuioiua]

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",
});

[iuioiua]

@kt3k, would you be in favour of doing this in v1?

[kt3k]

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).

[timreichen]

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.