search

elichai / log-derive

A procedural macro for auto logging output of functions
https://docs.rs/log-derive
Apache License 2.0
189 stars 12 forks source link

Log inputs of function too #11

Closed elichai closed 5 years ago

elichai commented 5 years ago

I'm trying to decide the best UX to support inputs too, This is what I came up with for now:

  1. keeping the macro the same but from now the logs will look like this: fibonacci(3) => 8. The problem with that is what if the input is too big?

  2. Do the second option but with a bool like with_inputs, if so should this be opt-in or opt-out?

  3. Make another macro with the same functionality and options as this one but for inputs only, pros: more functionality. cons: Harder to use and means 2 macro over the functions

TedDriggs commented 5 years ago

keeping the macro the same but from now the logs will look like this: fibonacci(3) => 8. The problem with that is what if the input is too big?

This also raises the question, what do you do if the inputs don't impl fmt::Debug?

Do the second option but with a bool like with_inputs, if so should this be opt-in or opt-out?

If you do this, I'd suggest making it opt-in, and possibly allowing the format string to use named arguments instead of positional ones.

Make another macro with the same functionality and options as this one but for inputs only, pros: more functionality. cons: Harder to use and means 2 macro over the functions

If you did this, how would you get the inputs and outputs into a single log-line?

elichai commented 5 years ago

@TedDriggs Thanks for the feedback.

That's exactly my problems, the second one means basically no normal nice configurations.

About the third I'm not sure how the TokenStream looks with 2 macros on the same function, Do I get the original TokenStream or the one that came back from the last macro?(and which one runs first)

TedDriggs commented 5 years ago

That's exactly my problems, the second one means basically no normal nice configurations.

As I think about this, input logging comes at a cost, both in terms of constraints on function input (it requires all arguments impl fmt::Debug or fmt::Display, which may make a generic function less useful), runtime performance (extra formatting calls, and keeping the formatted args in memory until the log line can be written), and log size. I think a lightweight opt-in is very reasonable.

darling helps here: You can derive FromMeta on enums to get very expressive options with minimal effort. If you think about what the options should look like, I can show you how to define those.

About the third I'm not sure how the TokenStream looks with 2 macros on the same function, Do I get the original TokenStream or the one that came back from the last macro?(and which one runs first)

I just tested this; it looks like the macros are invoked in order, and each one gets the token stream from the one before it.

elichai commented 5 years ago

I'm more thinking about the UX side. I don't care if it will even be very hard for me to implement. i.e. if It's opt-in in the same macro how would it look like to pass multiple fmts and different log levels etc.

elichai commented 5 years ago

Done :) and darling is a cool library, and I think i'll use it's Error's as my main errors.