[Discussion] API improvements and simplifications
BrainStone opened this issue · 16 comments
While I think that the API has been improved greatly from v4 to v5 I still think it has one major flaw:
Simplicity
In other words my main issue is that even to do simple things you need to use many aspects of the API and construct many intermediate objects.
So my main suggestion is to add overloads to all methods that fetch data and ask for a QueryOptions object. That overload would just not want one at all and do the same thing and just use a reasonable default value for it (like active player Contexts (if it's a player and they are online) or just the static sever contexts for other cases)
Now the question is what other areas of the API could use simplifications or reasonable defaults?
We are very open to your suggestions.
I tried copy and pasting some code from the wiki, and there were errors!
That's because you shouldn't copy-paste stuff, as stuff like that will happen.
That's because you shouldn't copy-paste stuff, as stuff like that will happen.
The wiki is actually outdated on many things. And quite a few examples use the old class names.
This has nothing to do with copy and pasting being bad etc. The docs are just not up to date.
While I think that the API has been improved greatly from v4 to v5 I still think it has one major flaw:
SimplicityIn other words my main issue is that even to do simple things you need to use many aspects of the API and construct many intermediate objects.
So my main suggestion is to add overloads to all methods that fetch data and ask for aQueryOptionsobject. That overload would just not want one at all and do the same thing and just use a reasonable default value for it (like active player Contexts (if it's a player and they are online) or just the static sever contexts for other cases)Now the question is what other areas of the API could use simplifications or reasonable defaults?
We are very open to your suggestions.
I'll break the silence here. This may seem off-topic but, you know what, I think we would be fine with the complex API, if only the wiki were more detailed. Being fairly new to Java, I have to say it's not that hard, all it needs is more explaining. Especially the part with the contexts, I still have yet to acquire help from someone back at discord, this just shows how little people know about it. I tried copy and pasting some code from the wiki, and there were errors!
Now, this is only an opinion from me, a fairly new person to Java, so I don't know if it's actually that hard to understand, but it certainly is for me, and I say you should really make the wiki more beginner-friendly as well as make the actual API simpler. If this ain't possible, at least do one of 'em. Please.
Sorry if that sounded more like a complaint rather than a suggestion, couldn't help myself. Here's a compliment: the part about how to use the plugin was very easy to understand. But hey, at least you got a suggestion from someone new to Java.
The wiki is actually outdated on many things. And quite a few examples use the old class names.
So are the Javadocs then, I presume? Some stuff I saw on the Javadocs contradicted what the wiki said.
The wiki is actually outdated on many things. And quite a few examples use the old class names
Examples please? As far as I know everything has been updated now.
So are the Javadocs then, I presume? Some stuff I saw on the Javadocs contradicted what the wiki said
The JavaDocs are likely to be correct if there's a contradiction. Could you tell me what the contradiction was and I'll correct it.
The JavaDocs are likely to be correct if there's a contradiction. Could you tell me what the contradiction was and I'll correct it.
My bad. After double-checking, it all made sense. Thanks for your time though. I guess the wiki wasn't made for beginners. Your ExtraContexts plugin helped me quite a lot but I just couldn't get my own one working (the tab complete works but everything else doesn't).
That's because you shouldn't copy-paste stuff, as stuff like that will happen.
That is true in a sense, but at that point I was really stuck.
I think MetaData can be simplified with using just one key to one value by default. I have never seen using one key for multiple values and I think most of the developers are using 1key<->1value. This would save some space without .get(0).
Why doesn't that method accept a node?
https://javadoc.io/static/net.luckperms/api/5.0/net/luckperms/api/model/user/UserManager.html#getWithPermission-java.lang.String-
P.S.: The javadocs should clarify wether or not that method considers inheritance or not (I'm assuming it doesn't but it's certainly not clear)
Currently for every group there's a node, however, imo it'd be way better if you could directly use User#getGroups or something, for a straight up list of groups, that way you don't have to loop through all groups and nodes to get a list of a users groups.
I'd suggest PermissionHolder#getGroups instead, but same idea. Also the QueryOptions thing I mentioned would be relevant here again.
Why not adding a simple way to access prefix from offline players in the API ?
It may be useful in many case where, for example, when you want to show the prefix of a player talking via discord with an account linked to a minecraft server, or when you make a "disguise" plugin and want to copy even the prefix.
Getting them is about as complicated as getting them for online players. So I'm not sure why you're mentioning offline players in particular.