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

Better sign handling #209

Open
ArtelGG opened this issue Jul 26, 2019 · 2 comments
Open

Better sign handling #209

ArtelGG opened this issue Jul 26, 2019 · 2 comments

Comments

@ArtelGG
Copy link

ArtelGG commented Jul 26, 2019

Improvement request

Describe the solution you'd like
A better way to handle signs while still maintaining cross-version compatibility;
block.getType().name().toUpperCase().contains("SIGN")
block.getType().toString().contains("SIGN") (pretty sure both will work just fine)
This will both, handle every sign variation (oak, dark oak, etc.) and handle wall and ground signs, all in one check.

Describe alternatives you've considered
What you have now may work, but it'll be very tedious to maintain over time.

Additional context
N/A

@Bart-0110
Copy link
Collaborator

While it can be used to read block information, it can't be used to place blocks. For example SIGN_POST and WALL_SIGN would both return true when calling String#contains. So there isn't a distinctive difference between the two.

Having both the old system and the one you suggested makes the code more scattered and harder to maintain in my opinion.

@ArtelGG
Copy link
Author

ArtelGG commented Jul 26, 2019

It's strictly functional as a getter, not as a setter. I'd wager if you felt like supporting every sign type it'd definitely make it faster in the long run if used properly, I'm sure you could hack together a setter as well using a similar method. At the end of the day, it is up to you though.

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

No branches or pull requests

2 participants