https://kotlinlang.org logo
#language-proposals
Title
# language-proposals
s

stantronic

03/30/2023, 3:05 PM
Hi. I have been following the discussion of the static extensions feature with great interest and the examples all center on functions and properties. Do you think the ability to add a new class under a given namespace/static object should be considered as part of that proposal; or would it be a separate proposal? My use-case is to disambiguate small data-classes which would naturally have the same name. I work on a HR app which deals with shifts and absences etc. We have a data class for
Shift.Duration
and one for
Absence.Duration
. At present these are nested classes, but it might soon be desirable to have them in their own file, or even in a separate module. Do you think this could be a possibility?
a

andylamax

03/30/2023, 3:37 PM
Looks like a namespacing issue, not a static extensions feature. But rather a static object (as it is proposed) feature. But yes, it is part of this same proposal
👍 1
j

Joffrey

03/31/2023, 7:27 AM
I know that's besides the point, but why do you need different classes to represent these durations?
y

Youssef Shoaib [MOD]

03/31/2023, 10:59 AM
@Joffrey Likely that is for type safety so that
Shift.Duration
is never used in place of an
Absence.Duration
. That makes it less likely to mess up the 2 durations
j

Joffrey

03/31/2023, 3:26 PM
But my point is exactly what is there to mess up? If those represent the same thing, they could be a single reusable type, which already exists as
kotlin.time.Duration
s

stantronic

04/11/2023, 11:28 AM
They don't represent the same thing. A shift duration is always in hours, and absence duration might be in half days and might be ongoing (in the case of sickness). They have different format methods for how they're displayed in app and we don't want one getting confused with another. the std-lib kotlin duration allows too much flexibility
👌 1
a

andylamax

04/11/2023, 12:47 PM
Perfect use case for having them different. kudos
j

Joffrey

04/11/2023, 12:59 PM
I guess the point where I see things differently is that a duration (as a "length of time") technically cannot be ongoing, it's just an amount of time. The absence itself can be ongoing, or the absence's period/span, but not its duration per se. So I guess if the absence's
Duration
class represents a time span with a beginning and an end moment, it would probably benefit from being renamed, and thus yeah obviously a different type. But yeah I get that having different units also might make arithmetic different for those types as a whole, so even without the "ongoing" property it would probably be justified to have different types
Anyway sorry for derailing the initial conversation
s

stantronic

04/11/2023, 2:18 PM
no worries 🙂
15 Views