Skip to content

Modern config compat layers #476

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
wants to merge 24 commits into
base: v1
Choose a base branch
from

Conversation

meowora
Copy link

@meowora meowora commented Jun 30, 2025

Description

Adds a compat layer for some of the most popular config libraries.

Closes #457 #458 #459 #461

Checklist

  • I made a clear description of what was changed
  • I stated why these changes were necessary
  • I updated documentation or said what needs to be updated
  • I made sure these changes are backwards compatible
  • This pull request is for one feature/bug fix

@Wyvest Wyvest changed the title moulconfig stuff :3 Modern config compat layers Jun 30, 2025
@meowora meowora marked this pull request as ready for review July 10, 2025 08:24
meowora added 2 commits July 10, 2025 10:27
# Conflicts:
#	gradle.properties
#	gradle/libs.versions.toml
#	minecraft/build.gradle.kts
#	minecraft/src/main/java/org/polyfrost/oneconfig/internal/OneConfigMixinInit.java
#	modules/config-impl/src/main/kotlin/org/polyfrost/oneconfig/api/config/v1/internal/ConfigVisualizer.kt
@Wyvest Wyvest moved this to In progress in OneConfig Jul 11, 2025
@Wyvest Wyvest requested review from Deftu and nextdayy July 12, 2025 07:20
import kotlin.reflect.KClass

@Suppress("UNCHECKED_CAST")
internal var Property<*>.visualizer: Class<out Visualizer>?
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

should we make this public?

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

idk your call

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@nextdayy what do you think

@nextdayy
Copy link
Member

i don't really see the point of the relocator system - can't you just have multiple mixin targets for the mixin(s) ?

@Wyvest
Copy link
Member

Wyvest commented Jul 12, 2025

i don't really see the point of the relocator system - can't you just have multiple mixin targets for the mixin(s) ?

we still need the main MoulConfigCompat class and we (meowora and i) concluded that doing it this way was the best

@nextdayy
Copy link
Member

I personally think all usage of kotlin reflect (including KClass) should be removed and replaced with just java methods, as the kotlin ones spin up so many methods etc that are considerably slower and unnecessary here.

@nextdayy
Copy link
Member

also I don't hate the compile time plugin stuff, but why not just use multi target accessors and mixins?

meowora added 2 commits July 22, 2025 11:54
# Conflicts:
#	gradle/libs.versions.toml
#	modules/config-impl/api/config-impl.api
#	modules/hud/api/hud.api
@meowora
Copy link
Author

meowora commented Jul 22, 2025

also I don't hate the compile time plugin stuff, but why not just use multi target accessors and mixins?

It would make adding new moulconfig instances a lot more complicated/annoying, I personally also feel like that would be way too much work, especially since the compile time stuff already works.

@meowora
Copy link
Author

meowora commented Jul 22, 2025

I personally think all usage of kotlin reflect (including KClass) should be removed and replaced with just java methods, as the kotlin ones spin up so many methods etc that are considerably slower and unnecessary here.

I don't mind either, just a decision what i should do would be awesome :3

@meowora meowora requested review from Deftu and Wyvest July 22, 2025 12:39
@Wyvest
Copy link
Member

Wyvest commented Jul 22, 2025

I personally think all usage of kotlin reflect (including KClass) should be removed and replaced with just java methods, as the kotlin ones spin up so many methods etc that are considerably slower and unnecessary here.

I don't mind either, just a decision what i should do would be awesome :3

i would prefer us using java reflection

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
Status: In progress
Development

Successfully merging this pull request may close these issues.

(feat): MoulConfig integration (feat): ResourcefulConfig integration (feat): YACL integration (feat): Fabric Mod Menu integration
4 participants