Skip to content

[RSDK-10933] use PlanningAlgorithm enum in favor of function pointer #5067

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

Open
wants to merge 2 commits into
base: main
Choose a base branch
from

Conversation

gvaradarajan
Copy link
Member

First of many PRs to clean up PlanRequest and plannerOptions.

This particular PR is the start of trying to remove function pointers from these structs wherever possible (due to them not being serializable or explicit)

@viambot viambot added the safe to test This pull request is marked safe to test from a trusted zone label Jun 18, 2025
}
}

func getPlanner(
Copy link
Member

Choose a reason for hiding this comment

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

We've been using the idiom of newX when writing functions that are constructors. This one definitely feels like a constructor rather than a getter. newPlanner is already taken so not sure what we should call this though

Copy link
Member

@raybjork raybjork left a comment

Choose a reason for hiding this comment

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

Just a naming note that would be nice to address but won't block over it.

}
}

func getPlanner(
Copy link
Member

Choose a reason for hiding this comment

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

I usually think of "get" as returning an existing thing.

We're actually calling the constructor here and generating a new planner. Maybe we name this "constructPlanner"?

Copy link
Member

@biotinker biotinker left a comment

Choose a reason for hiding this comment

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

LGTM mod one naming comment

Comment on lines 110 to 112
// Note the direct reference to a default here.
// This is due to a Go compiler issue where it will incorrectly refuse to compile with a circular reference error if this
// is placed in a global default var.
Copy link
Member

Choose a reason for hiding this comment

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

also not sure if this is relevant anymore

@viambot viambot added safe to test This pull request is marked safe to test from a trusted zone and removed safe to test This pull request is marked safe to test from a trusted zone labels Jun 18, 2025
Copy link
Member

@nfranczak nfranczak left a comment

Choose a reason for hiding this comment

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

🚀

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
safe to test This pull request is marked safe to test from a trusted zone
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants