Hi. I have been following the discussion of the static extensions feature with great interest and t...

# language-proposals

[stantronic]

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?

[andylamax]

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

[Joffrey]

I know that's besides the point, but why do you need different classes to represent these durations?

[Youssef Shoaib [MOD]]

@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

[Joffrey]

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

[stantronic]

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

[andylamax]

Perfect use case for having them different. kudos

[Joffrey]

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

[Joffrey]

Anyway sorry for derailing the initial conversation

[stantronic]

no worries 🙂