-
Notifications
You must be signed in to change notification settings - Fork 19
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
Support for log function genericity #19
Comments
For this particular example I think the simplest solution is to parameterise by level:
|
Indeed thanks... However I was looking at this in a slightly different context (and other implementation) where the argument would be optional and default to a kind of Of course this could be made to work with your solution if there was a Looking at this with a bit of hindsight though I think that the tags stuff in the msgf type was kind of a design error or over-engineering; unless someone actually uses that. Without this the type for logging funs would have been purely structural which would have allowed looser coupling for libraries. |
|
So basically @yallop is right here (parametrize by
with a good default level but also the ability to not perform any logging at all (because the messages might not make sense in a given execution context of the function). There could be two designs here. Design 1Keep things as they are and add:
This means that my functions are defined as:
with the default for Design 2In this design the level cases are augmented with a type level = Quiet | App | Error | Warning | Info | Debug whose semantic is to simply drop the log message. This would allow to write your functions as: val some_fun : ?log:Log.level -> ... with the default for In this design the options in the level reporting functions would become a bit redundant but could be kept to minimize API breakage disruption. With this API breakage would should be mainly limited to libraries that write their own reporters because of the case addition (however since I would tend to favour 2., any comments ? |
It is currently a bit difficult to define functions that are generic on the log function:
It seems the simplest would be to define:
Functions that want to be generic on log function then need to take a
'a Logs.func
argument:Is there maybe a simpler solution that I fail to see ? (/cc @yallop @Drup)
The text was updated successfully, but these errors were encountered: