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

Easier to register items #1826

Merged
merged 2 commits into from Apr 25, 2020
Merged

Easier to register items #1826

merged 2 commits into from Apr 25, 2020

Conversation

WalshyDev
Copy link
Member

Description

Instead of having to do registerResearch(Research, ItemStack...) you can just do new Research(..., items).register()

Makes this more consistent with the other registering too.

Changes

Varargs in constructor calling addItems

Related Issues

N/A

Checklist

  • I have fully tested the proposed changes and promise that they will not break everything into chaos.
  • I have also tested the proposed changes in combination with various popular addons and can confirm my changes do not break them.
  • I followed the existing code standards and didn't mess up the formatting.
  • I did my best to add documentation to any public classes or methods I added.

Instead of having to do registerResearch(Research, ItemStack...) you can just do new Research(..., items).register()

Makes this more consistent with the other registering too.
Copy link
Member

@TheBusyBiscuit TheBusyBiscuit left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't really see much of a benefit of why this should be added. Since this will cram it all in one line rather than the current method:

Research research = new Research(...);
research.addItems(...);
research.register();

But if you wanna add this to the constructor please make a seperate constructor with a this(...) call and then do addItems(...) to not break all addons all of the sudden. But then you of course wouldn't be able to have a varargs parameter anymore since there'd be constructor ambigiouty.

@WalshyDev
Copy link
Member Author

WalshyDev commented Apr 25, 2020

I don't really see much of a benefit of why this should be added. Since this will cram it all in one line rather than the current method:

I mean I can make the addItems return the instance so it can be chained instead but there's really no point making a variable JUST to add items. It's redundant. A construtor or chained addItems is definitely best I'd say.

@TheBusyBiscuit
Copy link
Member

I'm fine with chaining it. It'd at least be less intrusive and not break every addon in existence within a single commit XD

And depending on what we do with Researches in the future, a variable may be important to hold onto, got no plans for that though so feel free to chain it.

@WalshyDev
Copy link
Member Author

Chaining it is

@TheBusyBiscuit TheBusyBiscuit merged commit f4c5250 into Slimefun:master Apr 25, 2020
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

Successfully merging this pull request may close these issues.

None yet

2 participants