-
-
Notifications
You must be signed in to change notification settings - Fork 0
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
Comments
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? |
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 |
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 have already started working on XML comments, agreed with the cleaning / internalization |
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.
The text was updated successfully, but these errors were encountered: