If a member function only uses public members of i...

# announcements

[Dominaezzz]

If a member function only uses public members of it's class, should it be converted to an extension function? 👌/🚫

[Alan Evans]

sorry not a yes/no question

[Alan Evans]

an extension function:
- can require a new import line
- It looks different in IDE
- It can't be a member of an interface
If all of those things are OK for you, then can be a yes but it's not open and shut.

[karelpeeters]

Why would you convert it to an extension function? What's the advantage?

[Ruckus]

One advantage is you can override an extension function with a custom implementation without a extending the class.

[Alan Evans]

override an extension function? example please @Ruckus

[Dominaezzz]

@karelpeeters So do you only use extension functions to add functionality to classes that are not yours?

[Ruckus]

No, I often use them to accomplish the same purpose as static utilities in Java: provide functionality for a common use case that isn't fundamental to the class.

[Ruckus]

And for creating DSLs of course

[Ruckus]

@Alan Evans I'm probably misusing the word "override", sorry

[karelpeeters]

@Dominaezzz Yeah, mostly that. Also for cases where the extension function is only relevant for a single file, not for all users of that class.

[Alan Evans]

No problem @Ruckus. But what did you mean?

[Alan Evans]

I have used it in places where I want to keep dependencies apart.
Let's say I have MyModelObject and I want to map it to something else I might make fun MyModelObject.mapToDisplayObject(): DisplayObject
To make that a member function would mean MyModelObject file having dependency on DisplayObject, which would be yucky and maybe not even possible if they are in different modules.

[Ruckus]

Basically what I said above. You can provide a common use case to your users, but they can provide their own implemention if they want. That way they can still have the nice syntax for they implementation without having to meet with inheritance.

[Ruckus]

All they have to change is which function they import.

[Alan Evans]

but.... that's just using another function, which they can if your one is a member or an extension

[Alan Evans]

AFAIK, you can't override, so their function will have a different package and/or name

[Ruckus]

Yes, thus the different import

[Ruckus]

Of course there are other ways to accomplish the same goal (Java and other languages have been amazingly successful without such a feature). Kotlin just makes it nicer.

[Alan Evans]

sorry, don't follow.

You can provide a common use case to your users, but they can provide their own implementation if they want.

This is true no matter if you opt for a member function or an extension function.

[Ruckus]

Yes, but with an extension, they can use the same name and signature without having to extend the class. For example, say my library has a Color class, and a Color.mix extension that does simple linear interpolation. Someone wants to use my library, but wants the Color.mix function to do alpha blessing instead.

[Ruckus]

It's the same as Java static utilities, but with the nicety of Kotlin syntax.

[Alan Evans]

I see

[Ruckus]

You could easily do it with a different named function or plenty of other ways, but if you will only every mix your colors your way, it simplifies the mental model a bit and makes the code easier to reason about when reading (in my experience).