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

Clean, simple, easy API #10

Open
RenderBr opened this issue Dec 5, 2023 · 3 comments
Open

Clean, simple, easy API #10

RenderBr opened this issue Dec 5, 2023 · 3 comments
Assignees

Comments

@RenderBr
Copy link
Member

RenderBr commented Dec 5, 2023

At the moment, what we want to do with the Api class is create a nice access point for managing every type of data this plugin offers. While we have something working now, we want to split it up into more components to make things easier for the user, there is also still much to be done as far as it goes.

@RenderBr RenderBr converted this from a draft issue Dec 5, 2023
@Maxthegreat99
Copy link
Collaborator

Maxthegreat99 commented Dec 5, 2023

speaking of which, do we want our manipulation methods in the Api class or in the manipulated class itself? already started moving stuff like creating accs to the acc class itself, and other methods required to be on the class since the real balance variable is privated.

Also to "split up" stuff do we do something similar to what the TShock class does?

@Maxthegreat99
Copy link
Collaborator

Maxthegreat99 commented Dec 5, 2023

I also think we should comment most of our public methods since we are making an Api (we'd need to enable xml comments), we can even publish the Api on Nuget tho it'd add more work to do on releases, we also need to clean / internalize some methods which would'nt be useful to other plugins, stuff like localization or command aliases loading

@RenderBr
Copy link
Member Author

RenderBr commented Dec 5, 2023

speaking of which, do we want our manipulation methods in the Api class or in the manipulated class itself? already started moving stuff like creating accs to the acc class itself, and other methods required to be on the class since the real balance variable is privated.

Also to "split up" stuff do we do something similar to what the TShock class does?

Hm... I think both. It should be in the API, but the child classes should always reference the API's methods. I'm not sure if it's good practice, but I think it'd be convenient to split up the classes, yeah. Up to you, honestly. I am fine with whatever.

I also think we should comment most of our public methods since we are making an Api (we'd need to enable xml comments), we can even publish the Api on Nuget tho it'd add more work to do on releases, we also need to clean / internalize some methods which would'nt be useful to other plugins, stuff like localization or command aliases loading

I have already started working on XML comments, agreed with the cleaning / internalization

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

No branches or pull requests

2 participants