-
Notifications
You must be signed in to change notification settings - Fork 1.3k
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
feat(RelevanceSystem): addRelevanceEntity returns the relevant region #4902
Conversation
*/ | ||
public void addRelevanceEntity(EntityRef entity, Vector3ic distance, ChunkRegionListener listener) { | ||
public BlockRegionc addRelevanceEntity(EntityRef entity, Vector3ic distance, ChunkRegionListener listener) { |
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.
this function returns a new BlockRegion. do you want to change this to BlockRegion.
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.
Oh, I see why you might ask. Not sure. I'll explain my thought process and you can let me know how it lines up with expected usage convention of the joml and block *c
types:
ChunkRelevanceRegion is an internal class, and while its getCurrentRegion
method is public, I don't know anything about whether its return value is supposed to immutable, or always a current view, or fully mutable. If it's not immutable, I didn't want to have to try to figure out how to document the state changes of this internal class to external users of MTE.
I figure if we return a new copy, it's much easier to explain. We know none of the internals are going to change anything about this new copy.
Now maybe you're thinking that because we made this new object explicitly for this method call, we might as well let the caller take ownership and do whatever they want with it, right? No need to use the *c
interface to restrict the caller to a read-only view of it.
On the other hand, there's no reason to give them a mutable object. A person might expect that if they get back an object from RelevanceSystem with state-changing methods on it, that changing the state of it is supposed to actually change something. And it doesn't. That's why I went with BlockRegionc
.
I think this is the sort of place that will use a Record class as a return value, when we upgrade to Java 17 and get those.
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.
ooh, see yea I guess that makes sense. record class java 17? what is this record you speak of?
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.
Records for immutable data.
@pollend Your review says “changes requested,” is that still accurate? What have I missed? |
This is used by the code I'm adding so MTE knows when a region is ready.
No user-visible changes, as this method only returned
void
before.One wrinkle is that the return value only tells you the region's initial position. That's something that could change as the entity moves or resizes the region.