Commit Graph

9 Commits

Author SHA1 Message Date
229554d808 Implement User Data SQL Handling 2023-08-11 18:22:37 -05:00
305ebae9bf Attempt at fixing command registration
Signed-off-by: Paul Reilly <pawereus@gmail.com>
2023-08-11 15:58:40 -05:00
6ef6eacea0 Addressed requested changes
Signed-off-by: Paul Reilly <pawereus@gmail.com>
2023-08-11 15:26:26 -05:00
bbaa325ad6 Create Cladis (NetworkManager Hook)
Signed-off-by: Paul Reilly <pawereus@gmail.com>
2023-08-11 14:08:49 -05:00
8e5c52d0e8 Implement configuration system (#12)
* Return primitives in configuration interface where possible

This should save some unnecessary performance and memory overhead caused by the storage of object wrappers of the primitive types and the unboxing of those object wrappers into the wrapped primitive types when we try to do some primitive-exclusive operation.

I doubt that we'll be using the additional sugar methods that these wrappers provide most of the time, and if we need to we can just box the returned primitives.

* Mark returned lists in Configuration interface as Unmodifiable

I can't think of a use-case where we would want to modify the returned list from the Configuration interface we're accessing; however in case those situations do in-fact exist, I've made the decision to mark the return values of those methods as Unmodifiable so that there are no confusions in the future when the returned list throws an UnsupportedOperationException

* Provide class parameter in Configuration#getList

Otherwise, it's impossible to actually check if the on-disk configuration values are actually of the same type as/a subclass of what the plugin is expecting in the implementation.

* State that Configuration#getList will return an empty list if it fails

I don't think it would go particularly well if we were to return a list of Objects when we have a parameterized method. Additionally, how would components of the plugin respond to being given a list of Objects instead of whatever type they were expecting? This should be a better fail-safe solution compared to what we were previously going to do.

* Return an optional in Configuration#get if something went wrong

* Add class parameter to Configuration#get

* Update JavaDoc of Configuration#getList to reflect new parameter

* Remove final modifier from parameter

* Add class parameter to Configuration#getOrDefault

* Fix misspelled JavaDoc tag

* Partially implement a wrapper over FileConfiguration that implements our Configuration

* Fix codestyle violation

* Add copyright header & change package

* Add code for WrappedBukkitConfiguration#getList and WrappedBukkitConfiguration#get
2023-08-11 14:01:19 -05:00
086e5ca72f Added copyright notice to all class files (#23)
* Pushed copyright configuration to all classes

* Removed duplicated copyright headers
2023-08-11 19:41:38 +01:00
Eva
3e8c63221d Overhaul of Patchwork and Registration system, fix-up for all plugin.yml files and removal of .negates(0 and .value() from DefaultNodes in turn for the .expiry() system removing the redundancies. (#21)
Co-authored-by: eva <66324759+evax64@users.noreply.github.com>
2023-08-11 13:15:36 -05:00
9bb7ebb770 Changed phrasing to match latest changes. 2023-08-06 17:07:49 -05:00
21463c50fe Migrates the entire package nomenclature to be more direct and straightforward. (#17)
Signed-off-by: Paul Reilly <pawereus@gmail.com>
2023-08-01 22:34:18 -05:00