#dev-general
1 messages · Page 336 of 1
property-based injection > constructor-based injection
anyway, enough of that
what should I do?
Literally untrue
Leave it up to the consumer
yeah but then how do I get instances to give access to things like Server?
Very untrue
singletons are just
unless those singletons are Kotlin's object, in which those are amazing
why is instantiating the class your self bad exactly?
because then I can't DI instances of the Server from the backend when I load the plugin
why not?
why would I be able to?
Why don't you require plugins that to have a server as property of the constructor of the main class?
you have an instance of the server, just pass it when you instantiate the class
class Plugin(private val server: Server) : JavaPlugin()
Constructors if you don't want static
oh right, you're saying I should instantiate it myself James, I thought you were saying it was a bad idea for me as a developer to instantiate it myself
Yeah that's what I meant
I might just instantiate it myself tbh
no im saying what matt is saying
might be easier
That's literally what all of us are saying to do
right, so then an initialize method or something I guess for loading plugin shit?
(a bit like Bukkit's onEnable)
If multithreading is a focus (which it seems to be) you should probably be strongly discouraging state and mutability
not really, they could use the init block or constructor
^
eh, yeah
I'm thinking that an initialize function might make more sense though
and then shutdown for disabling
could you do what JDA does and have a shutdown event that they listen to
why not?
You have a choice here, go with the traditional bukkit API design and accept that thread safety will be hard, or use an actual concurrency model
Event driven works very well
Reactive works well
I don't like Velocity's method of listening for events for initialisation
state machines not so much
plugins will be initialised in a specific order all synchronously
that's not what's async
doesn't matter
it's the actual playing of the game that's all async
still seems nicer to use events
eh, I don't like that idea tbh
my vote is init/constructor/startup event & shutdown event, but its your project so its up to you lol
if you do that make it an open not abstract method por favor
one thing I definitely will provide though is heavy encapsulation and strong limits on what plugins can actually do
I wanna make Plugin an interface, so I can just make this a method with a default implementation
Inconsistent
I don't want plugins being able to disable other plugins for example
like none of the plugin management or loading should be visible in the API
oh yea
e.g. in Bukkit, you can call Bukkit.getPluginManager().disablePlugin(anyPluginInstance)
i guess i will just need to use reflection in order to take over servers
lol
the way I want this to work though, your plugin won't have any idea if any other plugins actually exist on the server
actually that might be a bad idea for dependencies
would fuck dependencies yea
but maybe I can do that another way
you can expose parts of the process so things like dependencies can work and then just make other parts like disabling plugins internal
or just make an interface that contains things like the list of plugins that exist maybe, but then do enabling and disabling on the backend
so plugins can't do any whacky reflection to access those methods at all
and if they want to access them, they've gotta depend on the backend
reflection would still give you access to the backend tho?
Trying to stop reflection is dumb
^^
yeah I shouldn't try to stop reflection
I've seen a few people building their programs around that philosophy
It's stupid
Reflection literally exists to bypass restrictions when necessary
I just want to make it clear that enabling and disabling plugins should be avoided, and I can put across that message by putting it on the backend
i just expose the stuff i thing they need, but if they want to use reflection and potentially fuck something up thats up to them
Exactly
just don't expose the enable/disable stuff
yeah that'll be on the backend
if someone chooses to use reflection to do it and they fuck something up thats on them
also, @JvmName is gonna be my best friend and my worst enemy
i feel like kotlin does a good job of that in most cases already
if you're using coroutines anywhere in the API you can already forget about interop
Does coroutines not work well with Java?
Not at all
coroutines don't work at all with Java
Not in the slightest
especially because of suspend
So none of the API functions will be suspending?
Seems an odd decision
¯_(ツ)_/¯
honestly if i were you I would say fuck interop and just make it a great kotlin api that suspends and does whatever it needs to do for performance
Mhm
as long as I call them from a coroutine context then all is well
bruh
actually maybe just saying "fuck you Java" is a good idea
why would you not make them suspending is the question
if they want to make plugins they can learn a superior language
Plugins in clojure yeah
it deadass takes like 2 days if you know java
That would be great
From the java POV such a library would just look like normal bytecode with callbacks and some method calls to kotlinx.coroutines library classes. So no different than any other asynchronous technique –
Wouldn't this be the same for plugins?
I mean, I don't think lucko will mind lol
suspending functions have an extra parameter added by the compiler
Which makes them pretty much impossible to call from java
Unless you somehow generate your own Continuation
Senpai
also, what would I even make suspending?
-_-
Yeah but what I mean is that a coroutine based server would call java code, that could would be run async in theory
The issue is when Java itself tries to use it, but since the server would be the one calling the plugin i don't think there'd be an issue
from my experience if you make one thing suspending, you make everything suspending
commands can be async if there is nothing we need to call sync, which in how I want to design Krypton, there shouldn't be
if only
If you suspend the whole server then nothing would be async 
suspending does not mean async
^
in fact, suspending means the complete opposite
the way you write coroutines is in a blocking way
you write code as if it's going to block (suspending functions) and then execute it in a place where it doesn't block (coroutine scope)
but coroutines are weird
That implies it means sync
Which is also untrue
true
this is a bit misleading
because the idea of coroutines is precisely to not have blocking code that just runs in a different thread
your turn it is then I guess
In essence, coroutines are callback-hell generated for you
lol
Mhm
also, instead of the method names addPermission and removePermission, I was thinking of using the names grant and revoke
e.g. sender.grant("some.permission")
or sender.revoke("some.other.permission")
oh also, I'm debating whether to use an Array<out String> or a List<String> for command arguments
?
with arrays in Kotlin, they don't have all the same functions that Iterables do
so you have to use an Iterator and Sequences if you want to not have arrow code and access those methods
What
example of what happens when things go wrong with using arrays https://github.com/Prevarinite/Punishments/blob/master/src/main/java/com/prevarinite/punishments/commands/BanCommand.java#L35
I mean, maybe that's just me, but ya know
¯_(ツ)_/¯
anyway, we using a list
That's horrible
oh btw, on a completely random note, what do you guys think of https://ajalt.github.io/clikt/ for handling command line params?
that isnt a problem in kotlin
not really appropriate
that's for "traditional" CLI
rather than something like kick [Player] [reason]
it could probably work
but isnt great
Then yes it's fine
oh also, should CommandSender have access to the Server like Bukkit's does?
that sounds unnecessary tbh
?
what
I mean should it have a value in it that allows you to retrieve the server
which is why I said it was useless
what are you talking about
Lost the talk about Koin :c
Koin is just great, works pretty well
In fact, I need to add some extensions in KotlinBukkitAPI to better support Koin
😠
What is your recommendation instead of Koin for DI?
Dagger2 is bullshit, Google DI also, Spring also
Personally I'd much rather use guice
Google DI = Guice
ik
same shit
Nothing wrong with Guice
Koin superior
people in the kotlin ecosystem have an obsession with reinventing the wheel to be more "idiomatic", even though it usually ends up worse
koin is utter trash
well, I don't see where Koin is worse
also, that's literally the entire point of Kotlin lol
no it's not
Here on my job, we use Dagger2, Koin and Kodein
make something that's easier and nicer to use than Java is
and has some cool features on the side (coroutines, time, etc.)
well, this is what the team from jetbrains say about kotlin
there is a difference between making an alternative to something to fix flaws, and "fixing" something that isn't broken
okay, I cannot stand "if it's not broken, don't fix it"
both are fine
what you thnking about ktxserialization
the only thing ktx does better is multiple languages
kotlinx.serialization superior though because it's more idiomatic
stfu
actually, maybe idiomatic isn't the word
just being able to have serialisers be auto-generated for objects instead of having to write them yourself is amazing
?
ktx serialization just work with Kotlin, Gson, doesnot
and taking out reflection
have you ever used gson?
samething about Guice
oh and being multiplatform
actually yeah Gson does a similar thing
you can use in Kotlin? chore, but I will lost a bunch of features
how does Guice not work with kotlin?
also, working with Kotlin libraries in Kotlin is generally better than working with Java libraries in Kotlin, as Kotlin libraries are (surprise surprise) made for Kotlin, and Java libraries are (again, surprise surprise) made for Java
you can have like a DI of Something<String> and Something<Int> and they are different
I find anyway
try to do that with Java
yes but interop exists
yes, that is a benefit (although im fairly sure Guice can do this too)
You can do this by passing DI Tags all over the place
but, does easy, no
There is alot of features that Java libraries simple can't support
and a lot of them aren't designed in a way that really works well for Kotlin either
or at least, not as well as a Kotlin library generally is
There is alot of libraries build in kotlin that have a big advance in beeing kotlin
not just for idiomatic
performance reason
e.g. OkHttp 4 is so much better to use than OkHttp 3
like Jetpack Compose or any library that use lambdas functions in inline modifier in kotlin
Jetpack Compose use ALOT inline classes to avoid memory allocation
e.g. MediaType.get("application/json") vs "application/json".toMediaType()
I hate having to call utility methods in Kotlin
it's just not the way it's meant to be
Lmao that's the most petty difference
You can forget all the kotlin only features, is not fair with any Java library, you can put just the features that the usage in code is exacly the same, but the performance is better
also, Java libraries are massive and confusing
because Java is massive and confusing
try for example Maven Aether
No good documentation, you will only learn from github projects that uses this shit
and Maven Aether is the most "Java" library that I can think (because I don't use java for long time and do not suffer anymore ❤️ )
lol
Kotlin good Java bad
that's just a fact around here
it's not even a matter of opinion in this channel lol
Is not just a fact, Java is still in Java 8
There is alot of people still using Java 8
I mean, can't really say the language is bad because idiots decide that using legacy versions is a good idea
it's like saying Minecraft is bad because most people still use 1.8
that's the problem with the library, not the language
Kotlin is developed by a company that knows all languages mainstream in the world
they do the best tooling for a bunch of languages
they know what they are doing
this is the fact about kotlin
Kotlin is only good because it had dozens of examples of what not to do lol
in my experience, I never have this problem with ANY kotlin library
i am not talking about the language
i am talking about a few prevalent libraries in the ecosystem
yeah BM thinks Kotlin superior to Java at least I think
namely Koin and Ktor
Ktor's DSL-based system is beautiful
But you say that "Kotlin libraries are despicable"
superior to Java 8
I said "koin is despicable"
with a bit of hyperbole
Kotlin is superior to Java 11 too
Java 14 too
maybe level with 16, but that's about all I'll give you BM
where is the Extension function, a really good Functional type system
to finish it
maybe that will be added to 17 lol
Where is Jetpack Compose?
then Java will start to look more like C#
Where is Fiber?
Java doesn't want extension functions
true
probably "not the Java way"
Dart, Swift
they've already addressed this
being... worked on...?
I mean, I don't think extension functions really fit into Java tbh either
exactly
and again, im not really talking about the language here
i have no problem with either language
i have a problem with the kotlin ecosystem's obsession with reinventing the wheel in a shitty way, adding a few 💫 idiomatic 💫 DSLs for configuration, and calling it a better library
also, about the reinventing the wheel, you are right if the Kotlin and Java was not complete different
huh?
okay, maybe not better
but Guice vs Koin is like comparing apples to oranges
it's personal preference imo
So you don't like mangoes is what you're saying
Field injection sucks
it's two completely different ways of doing dependency injection
that's your opinion
I only do constructor injection with Koin
field injection is pretty much an anti-pattern by now
can you even do that?
for the same reason static getters are bad
guice supports it too
but afaik dagger and Guice both heavily encourage constructor injection instead
of course, just instanciate everything in you modules
ah yeah, that'll work
I mean, one thing I do like about Koin is just how stupidly lightweight it is
About Ktor
there is a reason why kotlin does this
reinventing the wheel
Kotlin is multiplatform
Koin: 143 KB
Guice: 755 KB
Because it does no instance creation afaik
Kotlin should give you the ability to use anything from any platform, but it also should give you a way to do this for all platforms
yeah there's no whacky reflection or classpath scanning afaik
guice doesn't do classpath scanning
just reflection then
also, don't you have to configure Guice?
I remember Piggy saying something about you having to make some configuration classes or something
Modules?
that'll be the one
I mean, I haven't a clue how Guice works since I've literally never used it ever, so I'm just curious
also, someone please tell me the difference between plus and unaryPlus
I will admit being multiplatform is nice. However, my problem is with how the APIs are designed, not with their actual capabilities
Well... yeah, but you have to do that in koin as well...
3 + 4 Vs +32
maybe your problem is with libraries with much Kotlin features?
ah right
maybe is because you still are using alot of java
yeah
nah he spends his time with Haskell, Clojure and Elara mostly lol
and F#
ohgod 👀
I mean, Haskell is actually really nice
not sure about Clojure, it doesn't look pretty but it's a decent language I think
and F#, can't comment at all on that
lisp 
Haskell's pattern matching makes a when expression look like something out of the 80's
Do you folks want ternary operator in Kotlin?
same thing I think about Haskell or any language pattern matching comparing with Kotlin
Kotlin has baby level pattern matching
as I said, Haskell's pattern matching makes a when expression look like something out of the 80's lol
Which is funny, considering, Haskell
It has a specific range pattern? Isn't that just the normal in?
hello humans
is that a thing?
no, you do mean the regular in pattern I believe
It would be indistinguishable from value patterns otherwise
also, should I make getPlayer the method to retrieve players by name and UUID?
but, ya know, putting get in a function name in Kotlin just feels a bit... out of place
about pattern matching, for a scientist studding languages, sure, is "useful" but seeing the cases where pattern matching in Scala is use the most, is where kotlin already supports with when, my point is that is clear that the Kotlin team is not building a language with alot of feature, they are build a language with useful features, that you will use all the time
I kinda miss some features in kotlin, but I don't have any feature that I don't use
and comparing with like Java, Kotlin has alot more features
you I just use it all
This is why Haskell is cool but is not usage in the industry
haskell sure isn't a language rooted in pragmatism like kotlin
kotlin is not just pragmatic, it is also concise, in this is important
bit operators show what concise to Kotlin means
bitwise operations in Kotlin are horrible compared with other languages in terms of being concise
there's no assignment that can be done with them either, so you have to do something like variable = variable or 1 for example, like you're in some GCSE computer science class learning Python for the first time
what was the last time that you use bitwise operations that was not for minecraft or any type of protocol handling?
possibly the worst example you can pick
I mean, I can definitely say that it's more readable, but more concise? better?
in the world real, how much you will use bitwise?
actually quite a lot
also, even though I wasn't talking about concision, most functional languages are very much concise
I meant concise in language features, operators, not about the code it self
I don't get the meaning of concise in this context
if you are a CS, that will try to optimize a algorithm that also created in 90s, sure
in the world software world you will not use it alot
...except when you do
Not true
features/operators that really matters
I use them for educational purposes only, I regularly use Kotlin and Java
that is very subjective
bitwise really is useful
its often overlooked
many algorithms actually use bitwise and are severely reliant on them
Yes, they use, but how many times you will try this algorithms ?
If you are an algorithmic student like me
you would understand
🙂
they are the savior from getting a 60% to a 100%
The point is, should jetbrains add this because 1% of developers uses day by day, increasing language operators, increasing compilation time?
"educational purposes"
a.k.a circlejerking
It gets even better when you realise pattern matching can be used pretty much everywhere, rather than just case expressions
As far as I know
as I said, circlejerking lol
Predominantly learning and tinkering with in COC, but yes also circlejerking
clash of clans!???!?!?!!111one!
Haskell is used by Facebook and other companies
saying FP isn't used in industry is such an outdated comment
do ppl even know what circlejerking means lmao
It hasn't been true for many years
Apparently not
well it doesn't really mean that anymore
yea ig
But yes
I'm not talking about FP, I'm talking about Haskell
Elixir is new and shine and it is growing ALOT in the industry
As I said, Haskell is also used in industry
this is a non-argument in the case of kotlin, kotlin has so much syntax
yeah kotlin is a very syntax-y language
yes, but I use it all every day
doubt.
all the kotlin
i could count the times ive used crossinline on one hand
When do you have a bunch of Java apis that you need to make it better with Kotlin Inline Function
you will use all the time
increasing compilation time isnt the issue
specially in android
Hello Scala
for a Hello World project? sure
I swear Kotlin's compiler already has to do quite a lot anyway
since Kotlin has so many features
Kotlin's compiler is slow comparing with Java
you meant the new compiler?
because here with Android, is pretty close, but is not so much
compilation time of 30m here is normal with big apps
also, I swear you just contradicted yourself
you don't have microservice to salve you :c
im not joking
complaining about bitwise operators increasing compile time and then saying Kotlin's compiler is slow anyway
I also not joking
even though Kotlin's bitwise functions are more readable, that does not by any means make them "better"
more readable
More relaxed area to discuss development topics
Not configuration help
so u are saying to take out bitwise??
language operators, YES!
yes
in what world are kotlin's bitwise functions more readable
i cba to scroll up but im about 95% sure dedicated bitwise operators would make a negligible difference in compile times
I think shl is more readable than <<, since I just find it easier to read shl as "shift left" rather than having to think about which direction << is shifting
yes
it's literally 2 arrows pointing to the left
because < seems to sometimes be difficult for my eyes to read properly lol
<< is an established operator in pretty much every other C family language
yeah ik, I'm not saying it's bad, I'm just saying that I sometimes find it difficult to remember what it means
I've yet to see a language that uses shl as an abbreviation
And because of that, all languages should have?
also ternary operator?
no, but because of that, there is no reason to come up with your own cluttered language for it
I think bitwise operators are vastly superior, don't get me wrong, but I'm just saying that personally, for me, shl is easier to read than <<
you could make the same argument for && and ||
yeah until you run into parenthesis hell because of infix precedence
oh yep, I've come across that one enough times
bitwise operators is superior, of course, but the point is not what is the best and "bitwise operator is a edge case operator?"
what benefit is there to not using the known operators
yeah that was definitely a mistake on kotlin's part i think
^
also, bitwise operators aren't "edge case" operators
they are very common and very useful operators
if they were in fact "edge case" operators, then C and C like languages wouldn't have dedicated symbols for them
especially at the lower level, bitwise operators are very common and very useful operators
my head hurts
Java has native methods that call native code like C and C++. You should have bitwise operators in Java. Kotlin follows Java but it is less verbose. It has this same idea of native code as well. (cause C and C++ use a lot of bitwise)
yeah, sure, let's just write all of our network protocols in C and the JNI
Removing bitwise operating has no sense at all
when we use kotlin
Can do low level operations in Kotlin Native, but it was never build to do that
i dont get your point
we just pretend we'll never have to work with raw bytes
?
uhh wot
uh oh
lol
what's a byte? kotlin only has Int
Kotlin is not the language that you will do low level algorithm in it
let's just write all of our network protocols in C and the JNI
for the record: this is a joke
You will do this in Rust, C, C++
????
does anyone have a tutorial step by step on how to upload a jar to a vps from my pc and then run it? My head hurts to much to give docker another try
algorithms can be implemented in any language?
you crazy?
my algorithms are literally in Java
it doesnt matter what language I use
sftp + java -jar
sftp 🙂
thats the definition
of what an algorithm
literally is
otherwise it would be stupid
so now I need to set up sftp? great 😦
so, tell me why something: Why projects like bungeecord uses JNI for compression stuff?
sftp is ssh
Because why not?
sftp is there by default
oh
on most things
why not just write in java (and they write)
Why there is so many big projects in java using ALOTTTTT of binding libraries
for performance reasons
why just not write in Java?
rsync only sends differences, and supports built-in compression and other tools
You realize that an algorithm thats much better can perform 10x faster in java than compared to brute force in C
i dont think you understand at all
ok, and whenever we need this sort of stuff in kotlin as a base for higher level code, we are seriously supposed to resort to the JNI every time?
it depends alot
have you ever written to the JNI? it's horrible
?????
they know it themselves
java does not have any magic
huh?
java has no magic.
the compiler is pretty clever though
bitwise operators: too obscure, not appropriate to the language, not used
unaryPlus:
🤤 🐪
Not compiler, runtime, hotspot I think?
The JVM Compiler is pretty clever, but, if you say to me that Java will be 10x faster then a well writing C
I said the algorithm
dumbass
if the algorithm is smarter
of course it will run 10x faster
or even more
I'm talking about the same one
that tells me you didn't read the message lol
blockchain can make bubble sort the fastest sorting algorithm on the planet
pick like quicksort
the reason people turn to JNI/JNA for very specific and critical parts is that usually there are established standardised native libraries for those parts that no one can be bothered to port to the JVM
But, I mean, there is stuff beyond this extreme
It's not always so incredibly critical and highly optimised
if java is so good why isnt there the RUSt native interface
Java vs C, java will never be 10x faster with a well developed C
Maybe if I write in C it will
not always true
elara will always be at least 100x faster. that is the only certainty in the world
it is true, can't deny that
if java is so good why RUST exists?
but it's not a reason to dismiss basic operators
we have reached peak irony
because having to turn to the JNI every time you want to write something involving raw bytes... I think I'd shoot myself in the head
lmao
haskell native interface
JVM with Hotspot is just awesome, with a big project it will be faster the C, of course, the both developers in C and Java will make mistakes that well, Hotspot sometimes can fix it
but the C developer doing a stupid thing? no
public native static IO<Object> HS_putStrLn(String s) {
I just vomited
what
the
actual
fuck
is
that
haskell native inteface
well, if you NEED the operators, I mean << >> | & ^
for interacting with haskell when you want speed 🙂
you can technically use haskell functions in java
no way
well, haskell has an FFI so...
I assume it will get very messy very quickly though
amazing
((b as u32) << (c as u32)) as i32
public interface Monad<T> {
<A, B> Monad<B> bind(Monad<A> m, Function<A, Monad<B>> function);
<A> Monad<A> return(A a);
}
pragmatic
this is Arrow?
If I had less will to live I would try JNI + haskell now
But I'll leave that to you
😮
Arrow looks interesting https://arrow-kt.io/ this?
Adding on from impure languages 😫
interface Monad<T> {
fun <A, B> Monad<B> bind(m: Monad<A>, function: (A) -> Monad<B>)
fun <A> Monad<A> return(a: A)
}
Arrow Meta is more interesting
😎
I need to go deep in FP
kotlin cant be saved without a REWORK of syntax and CURRYING and PURE ITY
because I don't miss any thing from it
lol
java had it first
with mutating
C + Haskell + Rust = Casket
Seems like a subliminal message. Dont mix the pure with the impure
!!!
actually, not, is not the samething
and Java still does not release with
so.... Java simple does not have
kotlin devs see a java achievenment and try to STEAL it!!
Value Classes in Java will be immutable too?
every dev sees a haskell achievement and gazes in AWE
yes
when will we be getting type class HUH andrey??
thank god
Are value types in C++ immutable?
I don't know C++, I don't like C++
I remember their fields being assignable in C++
so maybe
Because Java already got records
for immutable data
The folks from Arrow want to add it
In java's case, value types are more than just language level constructs
also in Kotlin
Same in C++ as well tho?
when is not targeting JVM of course
every body gangster until interface Functor<T> gets added
how so? kotlin doesn't control the jvm
modifier pubfin extends final, public {
}
class MyClassWithFinalProperties {
//implicitly final!
pubfin String myPublicFinalString;
}
discord has brainfuck for code formatting
who tf is talking about c++
They just exist on the stack, that doesnt mean they have to be immutable I think
when is not targeting JVM of course
look up like 2 messages
the establishment is quaking
Value Classes at JVM Level will be just fucking great
does this arrow stuff have proper documentation?
not just overview articles and talks
i would hope so lmao
I'm having trouble finding it
WHIPPIng the dead horse
could you point me to it? the website is weird for me
Just choose what you want to learn
for example, it doesn't let me select the meta module and a tutorial type at the same time
core, fx, optics, meta
thanks
so you're telling me haskell is academic shit but when kotlin does it it's cool?
kotlin users alergic to parentheses... find a cure for cancer "DOES IT HAVE A DSL????"... no
obviously
havent you heard the news? kotlin good, every other language bad
breaking news
fun nextTalkCity(speaker: Speaker): Task<City> {
return
speaker
.nextTalk() .execute().then { x -> x
.getConference() }.execute().then { x -> x
.getCity() }
}
```ok call me biased but I've never seen this
what the
I don't use Arrow and does not like it
yep
dear god
interface Monad<F>: Applicative<F>, Functor<F>, Selective<F> {
fun <A> just (instance: A): Kind<F, A> // this comes from [Applicative] interface
fun <A, B> Kind<F, A>.flatMap(f: (A) -> Kind<F, B>) : Kind<F, B>
}```
This is why I don't like Arrow
well why not
just add boilerplate to code
Don’t be afraid of the “M-word” just because you are a Kotlin programmer.
I find this interesting, honestly
What is the m-word? xD
Oh!
monad ?
shhh
😱
Also, there was an article about function composition in kotlin
hmmm
but there was pretty much a compose function for every arity tho xD
not really sure if functional programming fits in Kotlin tbh
half of kotlin is inspired by functional programming
or at least, Arrow's functional programming
what is the difference?
an object is basically a singleton
It becomes a class the enclosing class keeps a singleton reference of
^
the best way to understand how Kotlin actually works is to click on tools -> Kotlin -> show Kotlin bytecode and decompile
oh
that will decompile bytecode generated by Kotlin to Java code
also, someone help with plugins pls
we've been over this
clientbound -> client
ik
which direction does the arrow point to
but i forgot
serverbound -> server
what does the arrow point to
so clientbound
does it point to the client or the server?
client
also, someone help with plugins pls
?
I wanna have a Plugin class, but no idea how to DI the server, folder and logger without loading the plugin within the API
and anyone who thinks I should use annotations, here's the door: 🚪
static 🙂
Use the door
dkim leave
👋
You don't like the idea of requiring the plugin to have the server in the constructor?
that's a shout
but that looks a bit ugly and increases boilerplate, especially if you have to DI the server, folder and logger every. god. damn. time you make a plugin
I want plugins to be able to log things
why not like Bukkit.getLogger()
just like in Bukkit, Bungee, Sponge, Velocity, just about any Minecraft API
https://github.com/SpigotMC/BungeeCord/blob/master/api/src/main/java/net/md_5/bungee/api/plugin/Plugin.java#L100 this is how Bungee does it (basically just copy and pasted from Bukkit)
but this logger will use SLF4J instead of Java's built-in logger, because SLF4J superior
^
wdym the caller?
each plugin
to decide what logger they use and how they obtain it
not the best idea
so they can choose whether to DI that or not?
ah right
so by using LoggerFactory.getLogger themselves or what?
you should definitely include some predefined way to get a logger
you probably dont need to inject it at all
yeah that's what I was thinking
yeah just make a property with a default value
also is it just me or can md_5 not code
allman, if ( statement ), Lombok
wtf
thinks Gradle is bad because it's imperative (which is kinda BS)
allman good
wait what
huh?
he said this once:
Imperative vs Declarative
A build system should be the latter, therefore Maven wins
Also Maven is almost always faster at actually building than Gradle
A build system should be the latter, therefore Maven wins
I mean gradle is declarative
Also Maven is almost always faster at actually building than Gradle
this is just plain wrong lol
md_5 has about 3 brain cells on a good day
(Also Gradle is almost invariably slower at actually building).
This was his actual quote
Source(s): Dude trust me
gotta love the wise potato lol
"It came from @md_5 ... that's enough of a benchmark. "
I'm still pondering at "Gradle is imperative"
e.g.?
val logger = LoggerFactory.getLogger(SomeClass::class.java)?
I am pretty sure that comment is sarcasm
maybe
Probably there is that you can't override it with a different logger type if you want
But I guess with slf4j that's not an issue
that sentence made no sense to me lol
that won't work anyway
since this is an abstract class and this property isn't open
then make it open
why?
also, you can't override SLF4J loggers with java.util.logging loggers can you?
also, I'm still trying to think of what I should supply to this getLogger call
maybe the name of the plugin rather than the class?
though it would really make people who name their main class Main look like a mug if I used the class lol
are you gonna require a plugin.yml
I want to use something like that yeah
the only other option really is annotations
and I like having a plugin.toml file anyway
yea true
or should I use YAML
toml is fine probably
but server owners dont like things that aren't yaml
TOML is really really bad for nested structures though
yeah
true true
that's kinda the point
i mean yaml is used by basically everyone in mc stuff
might want to keep it consistent
meh
just use clojure and toml ;)
could call it plugin.yml, or krypton.yml lol
lein new plugin
gonna loosely base this off of Bukkit's plugin.yml, with commands and permissions being optional though
true
if you want kyrpton in there do krypton-plugin.extension
nah I'm just gonna stick with plugin.yml
plugin.korm
I've just thought about the fact that I haven't even implemented the reflective loading logic yet lol
🥲
shouldn't be too hard
3 weeks later
lol
org.reflections:reflections:0.9.12 might make it easier
i used that earlier today to register commands for a plugin lmao
you know, contrary to its name, reflections isn't a reflection library
it's a classpath scanner
we know
also, how should I register plugin perms?
I could just steal the perms stuff from Bukkit I guess
although, do permissions really need to be registered as such?
I mean, Bukkit's purpose of registering perms is just for retrieval by other plugins
and descriptions/default values
and heirachies
you could make permissions plugins implement an interface/class like vault does
you could use bukkits thing
you could say fuck everyone and require luckperms as a dependency, then expose its API through krypton's api
yea probably
or just say fuck permission registering entirely, which is option 4
I think option 2 is the best though, so option 2 it is
I mean, I can always use Bukkit's loader as a reference lol
a.k.a steal it
if you do option 4, you make all plugins have to depend on every major permissions plugin and implement each one
what r u struggling with?
yeah that's not what I mean by not registering permissions lol
oh
as I said before, Bukkit's entire use for registering permissions is just for retrieval by other plugins
and /help
that's it
also, @prisma wave, here's one for ya
are you talking about registering them as in like plugin.yml permissions
how should I handle the plugin.yml descriptor?
what
I want to have the logger's name be the name of the plugin btw, rather than the class name
but anyway, I want to expose the descriptor to plugins
like Bukkit does
the what
basically the object that represents the plugin's plugin.yml file
oh like plugindescriptionfile
go for it reflection master
plugin interface defines an abstract val, "JavaPlugin" equivalent overrides it with the actual value
you could just pass it through the constructor
and which one exactly is inherited from?
?
which one do you inherit from to make a plugin?
oh
as your main class
the javaplugin equivalent
so basically just Bukkit
this is actually one of the few bits of bukkit that i think is quite nicely designed
then we run into the same issue
which is?
just use a constructor
but then we run into an issue here
Which is?
because plugins inherit from this, they have to call the constructor
and?
how can I have them not have to provide all the shit I do?
can they add the same things to their constructor
class MyPlugin(private val server: Server) : JavaPlugin(server)```
idk if that works
i feel like it might
that was what Matt suggested, but that gets messy when you have to DI the data folder, server and plugin description file
for every plugin
also, you suggesting I use a secondary constructor with lateinit properties BM?
absolutely not
e.g. ```kotlin
abstract class JavaPlugin() {
lateinit var server: Server
private set
lateinit var folder: File
private set
lateinit var description: PluginDescription
private set
constructor(server: Server, folder: File, description: PluginDescription) : this() {
this.server = server
this.folder = folder
this.description = description
}
}
Horrendous
You're looking for a replacement for something like JavaPlugin right?
I was just deciding if init is a good idea or not
for what exactly?
initialising the plugin
injecting the server, data folder and plugin description file
Id suggest having delegates that provide them
example?
also isn't this just kinda useless? what's the point in having a Plugin interface?
Plugin might as well just be a single abstract class
other implementations
might not be necessary now
but you can decouple the messy JP logic and the interface
true

