Replies: 5 comments 20 replies
-
|
Interested to hear thoughts of anyone reading this. 😃 |
Beta Was this translation helpful? Give feedback.
-
|
I thought we were kinda like forcing good code. They can always use the CompletableFuture#get to get the value, although I don't expect newies to know how to unwrap a Future. I don't have strong feelings towards this idea anyways. |
Beta Was this translation helpful? Give feedback.
-
|
The only thing I would add as a module, is a syncronise wrapper, that basically calls #get(). |
Beta Was this translation helpful? Give feedback.
-
Sounds like a brilliant way to satisfy both parties. |
Beta Was this translation helpful? Give feedback.
-
Alright. Is there any developed idea with the permission and chat API? |
Beta Was this translation helpful? Give feedback.
-
|
why does v2 get released before a new api? we need permissions api in v2 not just remove deprecations. also the documentation should also be paired to v2. of course you can not do it like that but then why would you want an undocumented, kinda featureless major version bump? |
Beta Was this translation helpful? Give feedback.
-
Agree with this |
Beta Was this translation helpful? Give feedback.
-
|
Personally, the reason I have yet to adopt Treasury is not due to difficulty, it's because I have yet to write a generified economy hook system, which was my original request when hearing about it. I recently wrote a system for handling optional dependencies and added a Vault handler a little while ago. Treasury isn't much more difficult and combining the two has a few fiddly design choices, but it's now on hold for 1.19 and whatnot. When I get that done my adoption will be a lot simpler. |
Beta Was this translation helpful? Give feedback.
-
|
I feel like an automatic Treasury/Vault handler is something we could undertake to (relatively) rapidly increase adoption of the APIs (even indirectly). My thought is to package that as a small shaded utility, separate from the Treasury project. |
Beta Was this translation helpful? Give feedback.
-
|
Strongly disagree on adding sync methods. Do you even have the slightest clue of what this can cause? |
Beta Was this translation helpful? Give feedback.
-
|
I/O on the main server thread is undesirable. If you firmly believe it will significantly increase adoption I'm not going to hold you back, but I don't think it's a good idea. If you want to invest efforts into encouraging wider adoption, imo the best use of your time would be to PR Treasury support into major economy providers and consumers. Proper implementations and usages can then (hopefully) serve as an example for less-experienced developers. |
Beta Was this translation helpful? Give feedback.
-
|
we're not adding the CompletableFuture by default then if you are having concerns of the (ab)use of
|
Beta Was this translation helpful? Give feedback.
-
Completely agree with this but what about what i posted literally 30 sec ago? |
Beta Was this translation helpful? Give feedback.
-
|
If we think a simplified future would help with adoption, sure. Definitely needs careful thought during design though - both of us missed unsafe usages due to the fact that default futures do not mandate error handling. |
Beta Was this translation helpful? Give feedback.
-
|
its not gonna feature a |
Beta Was this translation helpful? Give feedback.
-
|
Wait why are we releasing 2.0.0 before a new api?? It is a major version
increase after all, we need more than just removing deprecations.
На пт, 10.06.2022 г., 18:35 Lachlan ***@***.***> написа:
… Good point about get - I guess developers can just use it if they want to
go with a non-concurrent approach and deal with worse looking code as a
side effect.
I did forget about our mission to promote better code when writing this
post, it's something to also consider if anything changes based upon this
discussion.
Thanks for the reply. 😀
To be honest, is we want more users we should develop the other APIs. It's
been long enough since we released the economy one and we have a long list.
I'm thinking of this order:
Release v2 ➡️ Write documentation ➡️ Start work on permissions API
I'll have my freedom in a few days time to get back to working on the code.
—
Reply to this email directly, view it on GitHub
<#185 (reply in thread)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AJBTDWJL27AUJOSMG6R6AK3VONODZANCNFSM5YNGWIAQ>
.
You are receiving this because you were mentioned.Message ID:
***@***.***>
|
Beta Was this translation helpful? Give feedback.
-
I didn't plan on releasing v2 before new APIs, nor prior to new documentation being written. |
Beta Was this translation helpful? Give feedback.
-
Good day everyone! I've arrived to start yet another controversial conversation, though I strongly believe that this is an important factor for the future of the library hereon.
I am almost certain that the current lack of simple synchronous methods in Treasury's economy API is severely throttling the potential adoption of the library.
Ideally, we have async and sync methods in the API so developers can choose either.
I believe that their choice is in majority based upon these factors:
I completely agree that developers very well should be using Treasury in a concurrent manner. Although, the reality is that most developers do not fit all these criteria – some are willing to overcome it (e.g., how some of the current Treasury adopters have), but I believe that most are not. This leads into two further factors to consider:
The only significant selling point that Treasury has for the majority of plugins, is the thorough support for concurrency. Unfortunately, it's evident that a low proportion of developers are interested in writing concurrent programs.
A plethora of developers on the platform are young and inexperienced. There should be only little expectation that these developers are able to learn how to write concurrent code, which is somewhat complicated to do.
Beta Was this translation helpful? Give feedback.
All reactions