Hi folks, i am developing an SDK for my application's APIs and i have come across a dilemma, in requ...

# library-development

[George]

Hi folks, i am developing an SDK for my application's APIs and i have come across a dilemma, in requests like getAccount(): Accounts do you prefix your entities or not? Thanks in advance for any answer !

[mbonnin]

What do you mean? Something like ExampleAccount vs just Account ?

[George]

In regular cases like Account the conflict with the consumer app is pretty much guaranteed

[mbonnin]

I guess "it depends"

[mbonnin]

If you're one of the mainstream libraries like Okio, you can go for brevity: Buffer , Source , Sink

[mbonnin]

But if you're not, I would prefix

[George]

If i prefix only the most common (ExampleAccount) ones and the other which the conflict is quite hard to happen to leave them as they are, it would be weird?

[Javier]

you can avoid the conflict where it is happening using as on the import

[Javier]

import foo.bar.Baz as Baz2

[mbonnin]

Yea, alias imports are a solution but I don't feel super comfortable about them

[mbonnin]

If i prefix only the most common (ExampleAccount) ones and the other which the conflict is quite hard to happen to leave them as they are, it would be weird?

I'd vote for consistency first but then again OkHttp is a counter-example. They have OkHttpClient and Response

[mbonnin]

So I guess "it depends" each one personal taste

[Javier]

Same with ktor too

[Rob Elliot]

This is one of the very few places where I miss scala - the ability to import a package is really nice.

I prefer this:

import com.mything.web
import com.bank

val webAccount: web.Account
val bankAccount: bank.Account

to having to alias as you would in Kotlin.

[Javier]

Maybe @jessewilson or @jw can help us to understand that naming decision

[Javier]

@Rob Elliot you can workaround it by wrapping it with an object, and based on the file in which you are working you use Foo.Bar or you import Foo and use only Bar

[George]

Not a bad idea for `as`: if i were the consumer i wouldn't mind it, but i guess it depends on the consumer.

[Rob Elliot]

@Javier I don't follow - I'm assuming I don't control one or both of the types, I'm just a client of them. I can't nest a typealias inside an object.

[George]

@Rob Elliot
Im a bit confused, can we not write something like this in kotlin?:

val myServer = org.x.myProject.workhorse.entities.Server

[Rob Elliot]

I gather Kotlin had the ability to import a package but it was removed. There's this issue asking for it back:
https://youtrack.jetbrains.com/issue/KT-9242/Consider-returning-import-package
but it's from 7 years ago.

[Javier]

I was assuming we control one part

[Javier]

@George but partial import doesn’t work based on what @Rob Elliot said

[Rob Elliot]

@George yes, but that's really verbose particularly if you use the type a lot. In my example I'm only namespacing the type to the immediate parent package, not to the fully qualified package.

[jessewilson]

Two recommendations:
• don’t be afraid of short names: Request, Call, Json, Path
• don’t be afraid of short package names okio, okhttp3

[jessewilson]

Very few programming languages have a com.mycompany prefix in their naming, and as far as I know the actual collisions in practice don’t come

[jessewilson]

If you get a collision, like say okio.Path and java.nio.file.Path, you can just fully-qualify the Okio one