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

BLADEBURNER: Separate Bladeburner Console Automation from script API (refactor). #1678

Closed

Conversation

Alpheus
Copy link
Contributor

@Alpheus Alpheus commented Oct 5, 2024

No NS api changes. Impacted functionality is fully test-covered.

Motivation

Aiming to extract these functions, but would like a review of the scope change first. After review, the extraction will create a cohesive bundle for the Bladeburner Automation Console

Next Steps for Draft

  • Extract the private static methods to a separate js module.
  • (optional) Provide an interface to Bladeburner to denote all public touch points used by the Console

Review suggestions

The added files in Console/Commands are kept original verbatim except for translating this. to blade.
Github diff doesn't show that very well.

No NS api changes. Impacted functionality is fully test-covered.
… instance

Motivation: aiming to extract these functions, but would like a review of the scope change first. After review, the extraction will create a cohesive bundle for the Bladeburner Automation Console
@d0sboots
Copy link
Collaborator

d0sboots commented Oct 8, 2024

I'm not sure that this is actually an improvement in its current form. It seems to just be pulling a lot of functions out as private static, which... a) why even do that instead of just having them be free functions? (They'll automatically be "private" be being file-scoped.) b) These seem like they "belong" to the bladeburner class, so extracting them in this way seems anti-OOP.

@Alpheus
Copy link
Contributor Author

Alpheus commented Oct 8, 2024

I'm not sure that this is actually an improvement in its current form. It seems to just be pulling a lot of functions out as private static, which... a) why even do that instead of just having them be free functions? (They'll automatically be "private" be being file-scoped.) b) These seem like they "belong" to the bladeburner class, so extracting them in this way seems anti-OOP.

Alright

@Alpheus Alpheus closed this Oct 8, 2024
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.

2 participants