feat(plugin-api): userId & clientName getters

[viztea]

Adds two methods for getting the name & userId of a client

[freyacodes]

This is not idiomatic Kotlin. In Kotlin, if you have a property like val userId: String, which is a public final value, a getter is automatically created. From the perspective of Java, it would look like public String getUserId()

Interfaces in Kotlin support properties, not just functions.

You should thus:

1. Add the two properties to the interface
2. Remove the explicit getters
3. Remove the private access modifiers. Default is public.
4. Add the override modifier to SocketContext, e.g. override val userId: String

[freyacodes]

@devoxin @TopiSenpai just for future reference, the release of code changes to the API have to go through me, as I am the only one with credentials and who can sign releases.

[freyacodes]

Should probably also consider parsing the userId to be a Long. It's a string because Discord snowflakes are sent from Discord as strings in JSON for the sake of compatibility

[viztea]

This is not idiomatic Kotlin. In Kotlin, if you have a property like val userId: String, which is a public final value, a getter is automatically created. From the perspective of Java, it would look like public String getUserId()

Yes I'm aware of what idiomatic kotlin is. I attempted to have kotlin automatically create getters for me but it complained...

Interfaces in Kotlin support properties, not just functions.

ISocketContext is a Java interface.

You should thus:

1. Add the two properties to the interface
2. Remove the explicit getters
3. Remove the private access modifiers. Default is public.
4. Add the override modifier to SocketContext, e.g. override val userId: String

Properties inside of a java interface? I'm pretty sure this isn't idiomatic java.

[viztea]

Should probably also consider parsing the userId to be a Long. It's a string because Discord snowflakes are sent from Discord as strings in JSON for the sake of compatibility

Wouldn't that kind of be out of scope for this PR? It should be separate.

[freyacodes]

Fair, I didn't realise it was written in Java. That was a deliberate choice.

Wouldn't that kind of be out of scope for this PR? It should be separate.

Perhaps. But then you can do the conversion in the getter. I am not willing to release two separate API versions.

[viztea]

Perhaps. But then you can do the conversion in the getter. I am not willing to release two separate API versions.

Sounds good 👍🏼

[freyacodes]

Excellent. I will be releasing a new API version to Maven Central

[freyacodes]

Actually, we haven't really decided on how to manage plugin API versions that have not been merged into master. Are you fine with using JitPack for now?

[freyacodes]

API version 3.6.0 released