-
-
Notifications
You must be signed in to change notification settings - Fork 1.6k
Add blocks interfaces for commons properties #6639
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
base: minor-next
Are you sure you want to change the base?
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think the names of the interfaces are too verbose. I understand why (e.g. WoodType
would conflict with the WoodType
enum), but I don't like it much.
May be replace |
The aim is also to follow the name of the trait with the name of the corresponding interface, I think. If we were to rename these interfaces, it would probably make more sense to rename the trait accordingly. |
I'd personally favour e.g. |
In my opinion, syntax |
yeah I consider that but I don't really like any of the alternatives |
Perhaps for wood specifically we can follow copper's lead with |
So you want i remove |
Yeah, that's where I'm leaning right now. Welcome to suggest better alternatives. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The self
returns need to be documented as @return $this
Just my opinion, but what do you think about making facing interfaces to end on |
I don't have much opinion on that, aside from preferring consistency with the traits (since the traits and interfaces will typically be used together). |
This PR has been marked as "Waiting on Author", but we haven't seen any activity in 7 days. If there is no further activity, it will be closed in 28 days. Note for maintainers: Adding an assignee to the PR will prevent it from being marked as stale. |
class Wood extends Opaque implements PillarRotation{ | ||
use PillarRotationTrait; | ||
use WoodTypeTrait; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
WoodMaterial is missing
public function getOutputSignalStrength() : int; | ||
|
||
/** | ||
* @throws \InvalidArgumentException if `$signalStrength` is out of bounds |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should we really notice InvalidArgumentException
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
No, we typically don't document this since it's not supposed to be caught
* @return int between 0 and 15 | ||
*/ | ||
public function getRotation() : int; | ||
|
||
/** | ||
* @param int $rotation between 0 and 15 | ||
* | ||
* @throws \InvalidArgumentException if `$rotation` is out of hounds | ||
* @return $this |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If we give bounds here, we need to give it for the others
This PR has been marked as "Waiting on Author", but we haven't seen any activity in 7 days. If there is no further activity, it will be closed in 28 days. Note for maintainers: Adding an assignee to the PR will prevent it from being marked as stale. |
Related issues & PRs
Add #6161
Changes
API changes
Add:
AgeableInterface
AnalogRedstoneSignalEmitterInterface
ColoredInterface
CoralTypeInterface
LightableInterface
MultiFacingInterface
PillarRotationInterface
PoweredByRedstoneInterface
SignLikeRotationInterface
SingleFacingInterface
WoodTypeInterface
Behavioural changes
Backwards compatibility
No BC Break
Follow-up
Tests