Closed Oliver-makes-code closed 2 years ago
So, for the Drawbacks part, I left it as "TBD" because we can find drawbacks for it through discussion. There's also the unresolved questions, the first of which, "Should this be a subdivision QSL?"
QKL shouldn't be a subdivision of QSL, as QSL is based on Java, it'd be difficult for maintainers who don't know Kotlin to be able to maintain QKL. Having QKL as a subdivision of QSL would mean that changes in the respective QSL modules would have to be copied to the QKL module before merging. This is a bad idea, because it forces everyone to know Kotlin to be able to contribute.
Kotlin's interoperability with Java is just that, interoperability. There are some ideas that work well in Java, but not Kotlin, and vice versa. Extension functions and DSLs don't exist in Java, and with this we'd provide essential ones for modding in Kotlin. Also once CHASM is added to loader, we can provide an official front end for it in Kotlin
Couple of things:
- Firstly, if this team's sole purpose is making QKL, shouldn't they be the QKL team, just like the people making QSL are the QSL team? I understand there has been discussion about building Kotlin wrappers for things outside QSL (which I am all for), but that's been put under "Unresolved Questions".
The main reason is that Quilt Kotlin Team rolls off the tongue better, but it can be changed to QKL team if need be
- Secondly, if QKL will be for QSL libraries, wouldn't that be something like Quilt Standard Libraries Kotlin, or Quilt Standard Kotlin Libraries, not Quilt Kotlin Libraries? The name is inconsistent with QSL (it's not Quilt Java Libraries, after all).
QKL will be separate from QSL
QKL will be separate from QSL
I know, but since you're porting the standard libraries, it makes sense to say as much in the name.
We're not porting the standard libraries, per se, we're wrapping the libraries to make it feel more familiar to kotlin developers
All that's still TBD is the Drawbacks section. After that is filled out I can mark ready for review
The main drawback I can think of is that QKL may get out of date with QSL and/or the versioning scheme may cause confusion with QSL versioning (i.e QSL updates to 1.0.1 but QKL sticks on 1.0.0 as its not breaking) although that could be mitigated somewhat with minimum QSL version requirements
Open for review \o/
I think QSLK would make more sense
@Southpaw1496 The main reason I'm not going with QSLK is due to the fact it would cause people to presume it's a subdivision of QSL, which it's not
In accordance with the (not yet implemented) Governance Amendment #47, I would like to see you propose initial team members and the initial team lead. This would not be part of the RFC, but should at least be mentioned in a comment here so that people can approve of it.
In accordance with the (not yet implemented) Governance Amendment #47, I would like to see you propose initial team members and the initial team lead. This would not be part of the RFC, but should at least be mentioned in a comment here so that people can approve of it.
I can be the initial team lead, and @NoComment1105, @P03W, and I can be the initial members. @gdude2002 said he'd consider joining at a later date
I'd like to be an initial member as well
Definitely would like to be a member
I also would like to be in the team. 😊
I think it's necessary to point out that you can contribute without being on the team - it should not be a large team, and the people on it should be there to steer the projects that the team is responsible for, not just because they want to help with the projects.
Now that this has approval from all 3 admins this should be able to enter FCP
This RFC aims to define the Quilt Kotlin Team, and its uses