Creating a singleton in kotlin object companion just for con

Question

Creating a singleton in kotlin object companion just for constants like some INT codes my team uses in our files seems wrong What do people typically do Just have top level constants Or do people really just create companion objects

Vampire · Answer

For private constants I use top level declaration For non private constants it depends on whether I want them in the namespace of a class or standalone in the package

Colton Idle · Answer

We want them in the namespace of the class so that it s `ErrorCodes WARNING` for example

Vampire · Answer

Then there is no other choice than using a companion object is there

nanodeath · Answer

it even makes sense as a companion object property or `object`

Colton Idle · Answer

< Vampire> I guess that s what I m asking It feels wrong unidiomatic but maybe it s the right choice smile

nanodeath · Answer

is `ErrorCodes` a real class or just a bag of properties could possibly also be an enum class

Colton Idle · Answer

It s just a bag of Ints smile ```object ErrorCodes const val SOME ERROR = 1 const val SOME WARNING = 2 ```

nanodeath · Answer

yeah I suspect your best bet will either be what you re already doing or an enum class

Colton Idle · Answer

Thanks

Alan B · Answer

< Colton Idle> I would use an `enum class` as you can use them in `when` expressions and other things and then they truly represent a type `ErrorCode` Constants like that are then really just Ints but you lose all the goodness of a better abstraction the enum class as an `object` used that way can t enforce usage of the error code as any Int can be passed in to whatever you re using these for Also when you use a when statement without an `else` they must be exhaustive and you won t miss an error ```enum class ErrorCode val number Int SOME ERROR 1 SOME WARNING 2 val error = ErrorCode SOME ERROR fun handleError error ErrorCode String = when error ErrorCode SOME ERROR gt Error ErrorCode SOME WARNING gt Warning ```

nanodeath · Answer

gt Also when you use a when statement without an `else` if used as an expression slightly smiling face

Colton Idle · Answer

<https github com cashapp exhaustive|https github com cashapp exhaustive> too

Alan B · Answer

< nanodeath> Yeah I suppose I haven t run into that I never use anything but expressions in Kotlin if when try etc are all expressions in everything I ve written in Kotlin since before 1 0 I do not like side effects and I avoid `var` as much as possible which is usually about 99 9 of the time statistic made up but just for a point and my example broke my rule for brevity hah IntelliJ warns about not being exhaustive when not using it as an expression so I missed that on my example as I mentioned I tend to always use expressions but it didn t make sense for the example but my example was a bad one I ll fix that

Alan B · Answer

< Colton Idle> Interesting I have a total aversion to annotations as they are opt in just Like java s ` Nullable` People will forget to use them if it s not enforced by the compiler so really hard to trust In the case of that sealed class example it means that everywhere that class hierarchy is used the code must include that annotation to be consistent with its usage So again you can t trust that it s being used consistently Side note Not to mention annotations are annoying baggage that forever follow your code I do wish there had been a compiler flag to ` ignore unresolved annotations` perhaps with an argument list like someone using Spring persistence on their interfaces where I want the interface but not the baggage spring might bring along I wish annotations were comments with flair like javadoc or something to bypass the compiler if need be

Tomasz Krakowiak · Answer

< Alan B> there s a Retention SOURCE for annotations being a comment with flair

Vampire · Answer

Even with runtime retention they are not more than comments are they Unless someone evaluates and uses them

Alan B · Answer

< Tomasz Krakowiak> Ahh yes I see that the referenced ` Exhaustive` annotation used it It s just a gripe I have with runtime binary annotations slightly smiling face Let s say aspect based annotations are still baggage If I want to reuse let s say an entity without hibernate but its annotated to the hilt with hibernate or spring stuff the code is not reusable or you have to bring in all the dependencies that are there even if it doesn t require you to enable them Again this is just an annoyance I have with them It s not that big of a deal But it s something to take into consideration when designing a reusable independent API library That s all