Resource (ACF - BETA) Annotation Command Framework

Discussion in 'Spigot Plugin Development' started by Aikar, Apr 19, 2017.

  1. WAS

    WAS

    You should just have a utility class which is instantiated and determines server environment. Such as bukkit, sponge, nukkit, etc to save breaking pre-existing code.

    Also nit sure why each line is easier when it is recreating a annotation on each line. You could just syntax the previous example.
     
  2. No, because that would require including every single API into same module.

    Much simpler to just do -bukkit if you want bukkit. And as far as breaking changes, its literally 1 line to change.

    I'm not sure what you're talking about on 2nd statement. Can you reword?
     
  3. WAS

    WAS

    Oh nooo!


    Lol or have your "BukkitUtils" passed through a normal Utils class. Said class determines version running and links appropriate methods. I see this more than just having a bunch of utils to target; have a container.

    If your API is targeting multiple environments, like other frameworks, and APIs, it should handle it itself and not "lazily" (and yeah, I think it's lazy considering you can do it the other way) left to the end-user.

    Code (Java):
    @Command(aliases= {"kick" ,"gkick"}, info = "A command to kick a player", syntax = "kick <player>", permissions = {"plugin.kick"})
     
    Could be

    Code (Java):
    @Command(
        aliases= {"kick" ,"gkick"},
        info = "A command to kick a player",
        syntax = "kick <player>",
        permissions = {"plugin.kick"}
    )
    Or however the end-user chooses to style it syntax wise? Which looks 1000x better than your suggestion of just retyping the same annotations block over and over on each line, which does not look better. If one user thinks its a good idea, and I come in, also thinking it's a good idea, you're already not the majority, and should think about the people using your public resource. Again this sorta falls under-toe with things a Framework/API should be covering to allow flexibility. Especially in the accent-per developer that is Syntax.
     
    #83 WAS, May 22, 2017
    Last edited: May 22, 2017
    • Agree Agree x 1
  4. Sorry, I strongly disagree.

    Separation of concerns is something you will learn as you get into this career.

    Bukkit code has no business being mixed with Sponge, Bungee or other platforms (unless the plugin author WANTS to support both in the same jar file).
    Plugin developers should not have to shade in platforms they do not support.

    Also, the core is going to be abstract - it won't care about what game it is used in. That is not its concern.

    Say someone implements it for a game completely unrelated to Minecraft. There is no business for Minecraft code to be embedded in their jar file.

    I've followed this exact same pattern for TaskChain, and it works great.
    My libraries are being built to be game agnostic.

    I already responded to this here. That is your personal opinion. You're entitled to it, but I will not be changing it, as I mentioned in previous reply.

    If you choose to not use my API because it makes you type @ and ( ) a few extra times, then my feelings will not be hurt.
    But it will make me laugh.
     
    • Agree Agree x 1
  5. WAS

    WAS

    First of all, into the career? Lol, I've been developing for over 15 years, and have worked for various companies, and have deployed code that has helped shaped the modern web. You don't know me. At all. You know me working with a shit language more developers hate than not (though if you know my current career path, that's understandable -- we're natural born enemies) Lol

    Second of all, that makes sense now. See, I thought you were going to include the classes all together and just make the user implement the one he needed rather than separate jars for each environment. Never-mind what I said about that than. :p

    Since we're talking about opinions, I should probably make it clear, the posts is in regards to the fact that two people disregard your opinion for their own. Basically, we don't care about your opinion to put it bluntly, no offense. So talking about "laughing" is moot and is more and offense mechanism. It also doesn't cover the fact it's just lazy implementation of annotation. :\ There is even no reason you can't add it besides really being difficult. As you could still do it your way and live happily while other people could live happily having a better implementation and understandable code in their accent when using this system. Like pretty much every other implementation with multiple field options ever, and if they don't, again, I think it's more stems from laziness and not wanting to do it than any other possible reason.

    To each their own. Good luck with ACF! It's really cool.
     
    #85 WAS, May 22, 2017
    Last edited: May 22, 2017
  6. I apologize. I admit I assumed you were part of the 99% of teens just getting into programming in this community.

    But on to beneficial discussion. I'm going to spend some time this evening working on the ACF documentation, and hopefully when I get home, work on finishing the 0.5.0 transition to a modular format.

    I only had 1 issue left to resolve in -core, and I already figured out the solution there, so just need to apply it and then finish up acf-bukkit and acf-paper.

    After we release 0.5.0, I think I will start on some of the I18N work, which is what will give you the ability to customize all of the messaging in ACF such as permission messages etc, and let you support multiple languages.
     
  7. WAS

    WAS

    No harm.

    Also curious will there be a way to change localization at a whim? For example lets say there is a word in Low-Deutsch, and you wanted to use a word from High-Deutsch, will that be possible?
     
  8. I'm going to make it where you can load locale based files like en-US and en-GB for alternate languages. I believe we can even pull the players locale from their client settings maybe?

    But worse case, we make the plugin devs specify the player's language choice.

    Then you load as many language files as you want. (and if you don't want per-player languages, simply load 1 file as the default)
     
  9. MiniDigger

    Supporter

    yes, client sends that via client settings.
    I could have sworn that I created a PR for a PlayerLangChangeEvent before, but its not there...

    edit: meh, ill just create one
     
    #89 MiniDigger, May 23, 2017
    Last edited: May 23, 2017
  10. Main issue is that im targetting min 1.8 support :/ so if 1.8 didn't have an API to do like player.getLocale(), may be screwed on auto detection.
     
  11. MiniDigger

    Supporter

    can always just reflect into EntityPlayer. field is private String locale. idk when that was added tho.

    on other news, posted the PR, turns out that there was a PR already (guess the one I had in mind) from 21 Jan 2015....
    for those with a stash account: https://hub.spigotmc.org/stash/projects/SPIGOT/repos/bukkit/pull-requests/282/overview
     
  12. Hmm, may be able to pull this off safely since 1.8 is our min target and I think that fields been "locale" since then.
     
  13. @Aikar Noooooo bad... Make it Kotlin
     
  14. no.
    kotlin wrapper tho
    lit
     
  15. What would a kotlin wrapper even provide? I don't see how kotlin really would help end users use this.
     
  16. It would make it much MUCH less ugly
     
  17. Unless you're helping contribute to the project, what's it matter ;)
     
  18. And I'll try to get back to ACF soon - Had a busy 4 day weekend so I didn't even use my computer for like 4 days....

    I need to make some progress on my servers 1.12 update, but might try to get 0.5.0 out tonight.

    Maybe next week for the I18N work to let people change messages.
     
  19. I am helping contribute, by telling you it's ugly... :cool:

    (i kid, pls no attack)
     
    • Optimistic Optimistic x 3
  20. Java Master race! Embrace the java!
     
    • Agree Agree x 1
    • Funny Funny x 1

Share This Page