Hello! Apologies if this is a stupid question. Is ...

# naming

[Jacob Rhoda]

Hello! Apologies if this is a stupid question. Is there guidance for how to name something that conflicts with a language name / type? For example, I’m writing some code that handles measurements and units, and converting between units. Do I just name something “Unit,” and resign myself to writing kotlin.Unit to disambiguate?

[Chris Fillmore]

You have a unit that’s just called Unit?

[Chris Fillmore]

What exactly does your code look like?

[Jacob Rhoda]

Yeah, it describes a unit.

[Chris Fillmore]

But that is MeasurementUnit, so there is no collision with kotlin.Unit. You’re all good

[Jacob Rhoda]

Correct. That was the other name I came up with. Ideally I’d call it Unit , which is why I asked my question.

[Chris Fillmore]

Ah ok

[bod]

I think that's the right call. Calling it Unit is certainly possible but will make it difficult to use and that's the last thing you want for your library.

[Chris Fillmore]

Many codebases will have their own Result type, for example, which collides with kotlin.Result

[Chris Fillmore]

But that’s a good point from Benoit. If you’re creating a library, you may be better off avoiding collisions

[Jacob Rhoda]

Okay. I wasn’t sure if Kotlin had some convention or way to deal with interfering types. Sometimes there’s a convention, like prepending with a letter, or using some language feature to disambiguate.

[CLOVIS]

Sometimes there’s a convention, like prepending with a letter, or using some language feature to disambiguate.

There is: it's package names and import aliases. But those are the user's responsibility, so if it's a type you use a lot, it's probably worth having a different name to avoid the hassle

[bod]

if 100% of your users will rename your Unit with an import alias, you might as well do it for them 🙂

[Chris Fillmore]

Agreed. Many times I have imported kotlin.Result by accident

[Starr]

I've also seen SIUnit used for this problemspace

[Jacob Rhoda]

I wouldn’t be against SIUnit, however it would also represent non-SI units…

[Jonathan Olsson]

UnitDefinition, UnitModel, UnitBase seems perhaps like decent alternatives as well in addition to MeasurementUnit.