remove Logger.metadata property #36
Conversation
Motivation:
Logger had two ways to access the metadata:
logger[metadataKey: "foo"] = "bar"
and
logger.metadata["foo"] = "bar"
. The first one is the preferred API (as it doesn't force the
`LogHandler`s to store it in a dictionary) but the second one was still
available for cases where you need to import/export the whole metadata
storage.
Instead of exposing this as a dictionary, we should make the
'whole-metadata import/export' opaque. We're close to tagging 1.0.0
however let's design this API properly and add a sensible implementation
for 1.1.0 or so.
Moditications:
remove `Logger.metadata` property
Result:
- We can design the import/export APIs and add them when they're ready.
- the `LogHandler` API is unchanged
To sanity check my understanding of the phrase: We'll want to design a type that is "the metadata container" that could be then implemented in various ways, but not forcing it to be a dict?
Agreed with cutting out and designing well later for 1.1.0, I think I'd definitely have use cases for it (can open the ticket with an example use case). |
|
Btw, how are we treating APIs in sandbox mode with regards to source compat, e.g. if we suddenly find out that we have to change the way LogHandler has this defined? As with this PR it still has the |
Yes, we follow SemVer, so changing an existing API would mean |
Yes, totally agreed that there are use-cases, I hope to bring it back in 1.1.0 or so |
|
Cool, thanks for confirming. Happy to bump major even during sandbox time, no reason not to -- otherwise people and projects end up with "2.0 fear" 😜 👍 |
Agreed. We talked about it in the SSWG meeting and the idea is that the maturity levels and the version numbers are totally orthogonal. The only meaning attached to 1.0.0 is "we follow SemVer" |
Already here: #37 👍 |
Motivation:
Logger had two ways to access the metadata:
and
. The first one is the preferred API (as it doesn't force the
LogHandlers to store it in a dictionary) but the second one was stillavailable for cases where you need to import/export the whole metadata
storage.
Instead of exposing this as a dictionary, we should make the
'whole-metadata import/export' opaque. We're close to tagging 1.0.0
however let's design this API properly and add a sensible implementation
for 1.1.0 or so.
Moditications:
remove
Logger.metadatapropertyResult:
LogHandlerAPI is unchangedmetadatato start with and make opaque later #31