Open RenderBr opened 11 months ago
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
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
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.