-
Notifications
You must be signed in to change notification settings - Fork 12
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
Lazy message evaluation all the way #9
Comments
I agree that more lazyness would be great. Timberkt actually used to do something like your solution 1, but I changed it in version 1.2.0. The reason why is that the I also thought about your second solution, but then this library wouldn't be compatible with existing code bases that use regular timber, so I don't want to do that either. Maybe the right solution would be to make a PR to upstream timber to allow this sort of lazyness with inline methods. |
Oh hey, it's been there for half a year! If this works, with static imports the new multiplatform Timber renders TimberKt obsolete. Well, mostly ( |
I've been using this library for many years now thinking that messages are being evaluated lazily ... just to read now that it's not the case 😆 |
Lazy evaluation of the message is one of the selling points of TimberKt, BUT...
Currently TimberKt doesn't care if a tag is loggable or not. It evaluates the message string and lets Timber do the dirty work. The message evaluation happens always, including cases when the log would be discarded.
if (Timber.treeCount() > 0)
is just not good enough for this case.Example: I have a
CrashlyticsTree
that logs just warnings and errors to Crashlytics. However, all log messages are evaluated just so that debug, info, and verbose could be dropped later.Another example: Logging that's controlled at runtime. With a permanently attached tree.
or something like this
Solution 1)
Wrap the message lambda in a object that's only evaluated when timber gets to format the output.
This could be made more efficient maybe with inline classes or whatnot... Current cost of this is one extra wrapper object and one extra lazy delegate object per call.
Solution 2)
Well... totally copy Timber into TimberKt and adapt
prepareLog
method for Kotlin use style.The text was updated successfully, but these errors were encountered: