Skip to content
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

Investigate how to fall back to .toString where a custom override is defined #5

Open
lihaoyi opened this issue Jul 1, 2017 · 1 comment

Comments

@lihaoyi
Copy link
Member

lihaoyi commented Jul 1, 2017

This is something that old implementation did, and is great since for the times people use case classs for convenience but have a better string representation, it would use that instead of just enumerating the fields.

However, the old implementation relied on compile-time type inspection via macros, which is no longer available. We need some way to discover this using Java runtime reflection (we shouldn't depend on Scala-reflection, which is heavy/slow/buggy). As far as I can tell, "did the case class define a custom toString" isn't easily available from the bytecode.

Perhaps we could provide an annotation people can tag their case classes with, or an alternative pprintToString method they implement, to signal to PPrint that they would prefer to use their custom .toString instead of our generated default

@antonlin1
Copy link

I would like this as well. The use-case being not printing sensitive information for case-classes carrying secrets. They overload the toString in order to redact their secrets.

I wouldn't mind taking a stab at this. Any code-pointers welcome though :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants