-
Notifications
You must be signed in to change notification settings - Fork 602
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Redo log
#1404
Redo log
#1404
Conversation
…into rewrite-log
Some notes: I typed most of the docs on the train and will not be able to fix the resulting typos (one of the broken Macbook keyboards -.-) or words I have missed while revising until my return on Monday. |
From the talks we had about this, I think Tim and I agree on the overall composition concepts (log = dispatch -> handle, if you want multiple independent handlers there is some form of multi-logger that is arbitrarily nestable). Also as we have read each others proposals back and forth now and incorporated each other ideas into the different versions, this will be a collaborative result and a definitive improvement over the current module no matter what - we just have the luxury to decide between two versions :-) I added my (unnecessarily long, bikeshedding yay^^) perspective on the actual differences between the two proposals below - ultimately, the first point is the most important for me, because that one potentially affects all users who will ever log, not just logger authors. The API the loggers (not the module) exposeThis proposal sticks to the logger.audit("Things happened")
logger.critical("Something went deeply wrong")
logger.log("Someone did a thing that you should know about") The goal here was to make the actual logging part as concise as possible, because loggers get called a lot and those calls are all over the place in a codebase, while also sticking to a web standard(-ish) that JS devs are very familiar to. Tims proposal (at least when we discussed this and when I played around with his branch) did not do this, because, as far as I have explored, there is just no way to do that in a type safe manner with classes without having some wrapped API (which defeats the whole purpose of not having those). To class or not to classFor me, passing around callbacks is not a weird thing in JS - from In my mind, a logger basically boils down to a callback. Someone logs a message, the callback handles it. All of a loggers behaviour is that callback. The only thing that differentiates a logger from any function, is that it has the concept of levels with a threshold filter (in this proposal, the Yes, that can be modelled as a class and in Java it would definitely be. But Classes expose a very large API surface - that of writing a class with all options and syntax and pitfalls and implications - to someone who wants to write a logger, while we know that they very very likely will just want to set one callback to handle messages. I would personally also not call these functions factory functions - I do not think the term makes a lot of sense in the context of JS, as anonymous objects are first class citizens in JS (and have been around longer than "real" classes). Factory functions (as a JVM term) are a workaround for complex cases around classes, while functions that return new objects are a very common idiom in JS and not a workaround at all. So in the end, for me both approaches are valid at their core, but the functions expose a more streamlined, smaller API and generate less code in the module and for consumers writing loggers. The restThere are also some features that this proposal implements that are missing in the class based one - most importantly the concept of framework logging, which is a huge and important step to set a starting point that could benefit the ecosystem significantly down the line - but those are not too relevant for the decision, as they can be implemented in both approaches - that would have to be done though. |
Co-authored-by: Bartek Iwańczuk <biwanczuk@gmail.com>
Co-authored-by: Bartek Iwańczuk <biwanczuk@gmail.com>
Co-authored-by: Bartek Iwańczuk <biwanczuk@gmail.com>
Co-authored-by: Bartek Iwańczuk <biwanczuk@gmail.com>
Co-authored-by: Bartek Iwańczuk <biwanczuk@gmail.com>
I think this is ready now. I gathered some more feedback and applied several changes:
I think the pipeline is failing because the current import mechanism in code snippets does not work if the token does not exist in the current release - is that intended or am I missing something? |
Gentle ping - what's the latest update on this PR? |
closing because stale |
This completely replaces the
log
module with a module trying to achieve the following goals:console
-ish standard of<logger>.<level>(message)
also for custom log levelsThe
README
anddoc.deno.land
on the module should give an overview.The design of this module is heavily influenced by my discussions with @timreichen and input by @caspervonb .
This is marked as draft because it is still missing tests - I prioritized finishing docs so the picture is complete, as I promised @kt3k to post this tonight ;-)