I am having some trouble with visibility modifiers Basically

Question

I am having some trouble with visibility modifiers Basically I want a public getter method with a private setter for subclasses of a parent class The issue is if that parent class has a private variable it is not able to be set from the child classes so I have to have the parent have a public variable for the child classes to use it but now the var is public so the getter is useless In Java this was possible with the package private modifier which in Kotlin has been changed to module private so do I really need to create a new module just to hide some `vars`

ephemient · Answer

gt private for subclassees isn t that protected

Jordan Carlyon · Answer

Yeah but it cannot be used on top level declarations

Jordan Carlyon · Answer

I can work around that in an annoying and messy way though

Casey Brooks · Answer

Yeah I think you re looking to use `protected` on the `set` method of it

ephemient · Answer

fyi if you re just doing the default get set field you can leave out the bodies ```public var someValue String = protected set``` is equivalent to the definition in the previous image

Jordan Carlyon · Answer

the parent classes `someValue` can be modified by anyone though

Jordan Carlyon · Answer

oh I see the set and get syntax is very strange set and get are implied to belong to the field because the syntax is underneath it Not really clear on the scoping at play here

Casey Brooks · Answer

Java s package private doesn t protect against that either though Anyone could create the same package and access all the package private members And if someone is really determined to change the property they can eve bypass `private` fields with reflection `internal` is the closest analog Kotlin has to package private except that it actually does give strong guarantees around encapsulation in different modules It s difficult to truly ensure that a field is never modified except by your own code so the better route isn t to forcibly hide those fields bur rather provide sufficient documentation to let consumers know when they should and should not modify it so they can make the decision for themselves Using <https kotlinlang org docs opt in requirements html propagating opt in|opt in annotations> on those APIs can help make sure that the library users are aware of the concerns

Jordan Carlyon · Answer

How does get work The docs claim that it is a property on any var but I cannot just paste a get to random vars in main it gives an error

Jordan Carlyon · Answer

I don t really care about that though because I control the package I just don t want any consumers outside that package modifying it

Casey Brooks · Answer

Properties in Kotlin are not the same as Fields in java Rather a Kotlin property is more like a Java getter setter function The docs may clear it up for you <https kotlinlang org docs properties html getters and setters>

Jordan Carlyon · Answer

Where is the get syntax defined It looks like it can be named anything according to the docs but the compiler only allows get

ephemient · Answer

it is not indentation sensitive but context sensitive `get` and `set` immediately following a property declaration have special meaning otherwise they don t but by convention they are indented to visually mark them as belonging to the property

ephemient · Answer

it is documented here <https kotlinlang org docs properties html getters and setters>

Casey Brooks · Answer

The property itself can be named whatever you want `val stringRepresentation String` is the property `get ` and `set value ` is the specific syntax for customizing the accessors of the property Anyone accessing the property with `myClass stringRepresentation` will not care whether the property internally uses the `get ` or `set value ` accessors or not

ephemient · Answer

well they also have meaning as annotation use site targets but that s in a different unambiguous context

Jordan Carlyon · Answer

ok weird so get and set have to be named get and set and get has to come before set

Jordan Carlyon · Answer

actually the order doesn t even matter just the names

ephemient · Answer

like many of Kotlin s keywords they are soft keywords they have special meaning in specific context only

Casey Brooks · Answer

With property accessors you re not defining your own functions you re using language keywords The compiler creates the appropriate functions and maybe a Field for you in the Java bytecode using the name of the property they re attached to It s a bit weird at first if you re thinking of it like a Java Field but if you get used to the fact that a property is shorthand syntax for get set functions it will make more sense And Kotlin is literally creating standard bean style functions based on the properties see here how you cannot write a custom `getSomeValue ` method because the compiler is already creating a method with that name from the property

Jordan Carlyon · Answer

seems like there is a ton of soft and fuzzy logic in Kotlin

Jordan Carlyon · Answer

makes it really hard to read the docs are there any other docs that explain things more thoroughly Like what is actually happening

ephemient · Answer

soft keywords are not unique to Kotlin Scala has Python has and Java is them

ephemient · Answer

it is not soft and fuzzy logic by any means it is 100 defined in the grammar

Jordan Carlyon · Answer

anyways it seems like what I want to do isn t possible in kotlin I just wanted to make an enum or sealed class with a public getter private setter

ephemient · Answer

public getter private setter is literally ```public var property Type private set``` it sounds like what you want isn t private but more like protected or internal

Jordan Carlyon · Answer

yes useable for children which are enums and sealed classes

ephemient · Answer

then that is `protected` not `private`

Jordan Carlyon · Answer

protected doesn t work because they are top level members

Jordan Carlyon · Answer

so essentially I wouldn t even be using sealed classes or enums at this point just deconstructing them and reconstructing them with open vars or something similar

ephemient · Answer

you have a top level mutable property that is bad design and cannot participate in the class hierarchy

ephemient · Answer

but top level `private` is really file private so that does give you some options

Jordan Carlyon · Answer

I want a top level property that can be modified based on which type the class is

ephemient · Answer

just to clarify top level means outside of any class e g at the file level is this really what you mean

Jordan Carlyon · Answer

reading the kotlin docs it looks like top level meant at the top level of the class ie ```class Test var topLevel class subClass ```

Chris Lee · Answer

```class Foo private val onlyVisibleInThisClass String protected val alsoVisibleToSubclasses String internal val visibleToEverythingInThisModule String public val visibleToEverything String ```

ephemient · Answer

where in the docs does it say that

Jordan Carlyon · Answer

I cannot find it now but that is how it was appearing to work earlier when I tried to use this for sealed classes

Chris Lee · Answer

is the issue perhaps with nested inner classes vs inheritance in your example subClass is NOT a subclass it s a nested class It s only a subclass if it inherits as in ```class subClass Test ```

Jordan Carlyon · Answer

I think in a sealed class they are all inheriting by some fuzzy implied logic

Chris Lee · Answer

no they are inheriting by what you specify as the parent class

Jordan Carlyon · Answer

I don t think that s accurate

Chris Lee · Answer

it is sealed classes reflect an inheritance hierarchy

Jordan Carlyon · Answer

There s some weird dual return type inheritence structure going on

Chris Lee · Answer

no implement with standard inheritance

Jordan Carlyon · Answer

ok

Jordan Carlyon · Answer

so it sounds like I am not specifying it it s being inherited

Chris Lee · Answer

if you don t specify the inheritance there is no inheritance relationship

ephemient · Answer

they are only inheriting if you declare them as inheriting the structure is unrelated

Jordan Carlyon · Answer

```sealed class SealedClass object Child ```

Jordan Carlyon · Answer

Child is a subclass of SealedClass

Jordan Carlyon · Answer

I didn t specify that it was implied by the structure of the class

ephemient · Answer

that is only a nested class you need to state `Child SealedClass ` to make it a child it does not matter if it is nested or not

Casey Brooks · Answer

A sealed class can have nested classes defined without them being subclasses You have to explicitly extend the parent class for the class relationship to take effect

Chris Lee · Answer

```public abstract class BaseClass public sealed class Child1 BaseClass public sealed class Child2 BaseClass ```

ephemient · Answer

exactly it doesn t matter whether `Child1` and `Child2` are nested inside of `BaseClass` or not

Chris Lee · Answer

yep this is equivalent ```public abstract class BaseClass public sealed class Child1 BaseClass public sealed class Child2 BaseClass ```

Jordan Carlyon · Answer

Ok I see the kotlin compiler is having trouble distinguishing this

ephemient · Answer

it is not trouble it is intentional and the same as other languages

Casey Brooks · Answer

This behavior is also different from Java In Kotlin a class defined inside another is by default like a Java static inner class You can use `inner class` keyword to make it like the default Java nested classes

ephemient · Answer

inner classes are a type of nested class but still not a child class

Jordan Carlyon · Answer

thanks

ephemient · Answer

Java ```public class Parent static class Nested extends Parent class Inner extends Parent ``` without `extends Parent` they are only nested not children

Jordan Carlyon · Answer

yes I prefer the java syntax it s much more clear what is happening there

Jordan Carlyon · Answer

kotlin just makes everything look like a return type

Jordan Carlyon · Answer

I really dislike that about kotlin they try to fold all the naming and syntax conventions into a small numbers of things that have many different contextual meanings

Jordan Carlyon · Answer

it makes the code much less readable

Casey Brooks · Answer

Most newer languages are doing the same thing though It makes things a lot nicer in a world with type inference <https elizarov medium com types are moving to the right 22c0ef31dd4a>

Casey Brooks · Answer

Just takes some getting used to

Casey Brooks · Answer

Anytime you switch languages it s going to feel uncomfortable at first But once you get used to Kotlin you ll find it s an objectively better designed language than Java in most situations being overall more concise and the intent of your code more clear