Michael Langford
11/17/2021, 6:28 PMenum class AdmininstrationReason {
Prophy,
StudyPlacebo,
LightTherapy,
DrinkingRelated, //<- We might want to display this as "Swallowing Disorders"
Clotting,
Other;
}
So I certainly can implement it as above and then use automatic parcelize/@Parcelable stuff and it works.
I can even add an annotation and then get clever when displaying the value. This causes a performance hit by possibly dipping into reflection.
I can make a companion object and use associatedBy to get part of the way there, but this breaks automated parcelization.
I can make vals with getters for specific properties and use that, but it makes the per-item edits non-local to the list.
I could make every item have a "String" value with it, but I don't want to have to add strings for some of these entries (of which there are hundreds) and duplicate the name of the items in an error prone matter.//FYI: Codable is essentially Swift's Parcelable
enum BodyPartNames:String,Codable,Equatable {
case Hand
case Wrist
case Forearm
case Elbow
case UpperArm = "Upper Arm"
case Shoulder
case UpperBack = "Upper Back"
case LowerBack = "Bottom of Back/Spine"
/// many other cases, almost all of them with no special string
}
enum class Planet(var population: Int = 0) {
EARTH(7 * 100000000),
MARS();
override fun toString() = "$name[population=$population]"
}//from <https://devtut.github.io/kotlin/enum.html#functions-and-properties-in-enums>
@Parcelize
enum class AdmininstrationReason:Parcelable {
Prophy,
StudyPlacebo,
LightTherapy,
DrinkingRelated{
override val displayName:String get() = "Upper Arm"
},
Clotting,
Other;
open val displayName:String
get() = name
}
This compiles, but I see literally 0 other people doing this, and worry I'm doing something really ill-advised or incompatible with something when doing it.Joffrey
11/17/2021, 7:13 PMenum class AdmininstrationReason(val overriddenDisplayName: String? = null) {
Prophy,
StudyPlacebo,
LightTherapy,
DrinkingRelated("Swallowing Problems"),
Clotting,
Other;
open val displayName: String
get() = overriddenDisplayName ?: name
}
That being said, for your specific use case, I would actually really recommend using an actual string in the constructor for all entries. Using the enum value name as display name is sensistive to refactoring. It's much clearer IMO to use a separate value explicitly. It also opens the door more easily to localization and such.
I could make every item have a "String" value with it, but I don't want to have to add strings for some of these entries (of which there are hundreds) and duplicate the name of the items in an error prone matter.I find it more error prone to use the name of a variable/constant in code as something that's displayed to the user. Variable names and constant names should not matter to the execution of the program, they should be for developers. IMO I should always be able to refactor/rename any variable without having any impact on the business
Michael Langford
11/17/2021, 7:20 PMJoffrey
11/17/2021, 7:21 PMMichael Langford
11/17/2021, 7:26 PM