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

Ignore classes that inherit non-synthetic toString #34

Open
kubukoz opened this issue May 11, 2021 · 5 comments
Open

Ignore classes that inherit non-synthetic toString #34

kubukoz opened this issue May 11, 2021 · 5 comments

Comments

@kubukoz
Copy link
Member

kubukoz commented May 11, 2021

Given a class that has a toString defined in a parent (which isn't Object), which isn't the toString generated automatically for case classes, we should not define a custom toString for that class.

@carstenlenz
Copy link

carstenlenz commented Jun 7, 2022

That would be helpful - We just noticed (after updating) that we 'accidentally' relied on #59 - we use better-tostring together with enumeratum - and the upgrade broke all places where enums where looked up via string (as the encapsulating object is now the prefix in the toString method of the enum case object).
A simple 'dummy' (e.g. override def toString = super.toString) could then help with this in a custom base EnumEntry class - which I had to add now anyway to build a custom entryName without relying on toString.

@mrobakowski
Copy link
Collaborator

We have the exact same problem (b2s + enumeratum). I tried fixing this before, but I couldn't find a reliable way to do this other than generating toStrings which at runtime check via reflection if any of the parent classes defined their own toStrings... which needless to say isn't ideal.

Currently, the (scala 2) plugin operates right after the compiler's parser, so we don't have any types or even resolved symbols. I tried moving it somewhere else down the pipeline, but it broke more than it fixed :/

@carstenlenz
Copy link

carstenlenz commented Jun 7, 2022

@mrobakowski for enumeratum you could simply define your own base trait to use instead of EntryName couldn't you? defining a entryName method with s.th. like getClass.getSimpleName.<stripOfLastCharIfItIsDollar> at least fixes enumeratums logic.

@mrobakowski
Copy link
Collaborator

@carstenlenz yeah, that works (and is in fact better than our current workarounds, so thanks 😄) for enumeratum.

However, I would really like this to just work out of the box. I'll try again to mess around with compiler stages because I think we run after the typer in the scala 3 version, so perhaps there is a way to do this properly in scala 2 as well. Unfortunately, my experience with scala compiler plugins is pretty much limited to just this project, so it may take me a while (if it's possible at all).

@kubukoz
Copy link
Member Author

kubukoz commented Sep 23, 2022

getClass.getSimpleName.stripSuffix("$") seems to work for now :D but yeah, it'd be best to do this right here in the plugin.

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

3 participants