Skip to content
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

Consider visibility modifier of @Lenses annotated data classes #773

Open
haukesomm opened this issue Jun 27, 2023 · 2 comments
Open

Consider visibility modifier of @Lenses annotated data classes #773

haukesomm opened this issue Jun 27, 2023 · 2 comments
Labels
discussion Extra attention is needed enhancement New feature or request

Comments

@haukesomm
Copy link
Collaborator

haukesomm commented Jun 27, 2023

Current state

Currently, when a data class has a visiblity modifier other than public, the generated lenses will leak their non-public receiver type. This causes the compilation to fail.

Example:

@Lenses
internal data class Test (
    val someProperty: String
) {
   companion object
}

Generated lens:

public fun Test.Companion.someProperty(): Lens<Test, String> = lensOf(
// ^^^
// + public is no valid visibility modifier since `Test` is internal
  "someProperty",
  { it.someProperty},
  { p, v -> p.copy(someProperty= v)}
)

Suggestion

The data class's visibility modifier should be used in the generated lenses.

@haukesomm haukesomm added the enhancement New feature or request label Jun 27, 2023
@Lysander
Copy link
Collaborator

Lysander commented Aug 7, 2023

This sounds totally valid, but in order to understand the necessity of this issue, can you provide some (real world) example or use case, where one needs some internal or more general some none public data class for store mappings?

@haukesomm
Copy link
Collaborator Author

haukesomm commented Dec 29, 2023

In a real world application there might be a project that is structured like this:

<root module>
|
+-> core
|   |
|   +-> commonMain (shared model classes, etc.)
|
+-> ui-lib
    |
    +-> commonMain (ui-lib-internal model classes used for state handling etc.)
    +-> jsMain (actual components)

In the example above there might be some data classes that are internally used in the ui-lib for state handling but that should not be exposed to the outside world. Those would typically be marked internal.

In order to be able to fully use them with Stores (mapping), it would be convenient to still be able to generate lenses for them.

If the entire class is marked as internal, all lenses generated for that class could be marked internal as well.
If only a specific property is marked as internal, only the respective lens could be made internal, retaining the other lense`s visiblities.

Also, after some thinking about the matter, one could argue that only the internal visiblity modifier needs to be considered since in data classes protected is virtually the same as private and private doesn't make much sense in lenses.

@haukesomm haukesomm added the discussion Extra attention is needed label Dec 30, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
discussion Extra attention is needed enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

2 participants