Replace Interface with Type

Language Design
1

I’ve been years in java and kotlin, i don’t really enjoy using “interface” since the usage is often ambiguous. In common scenario i do use “interface” as a contract for open interface. But in general, i do need to define “type” , “pattern/structure”, “interface”. And the longer i code, the more i need “type” or “pattern” instead of “interface”. It (interface) does works for declaring type and pattern, but it ambiguous.

I highly suggest to use “type” since type can contain interface contract, and can also works as pattern declaration.

Im not a fan of inheritance, open class, abstract class, no body does imo. I prefer using pattern and pattern segregation. What is interface segregation anyway.

instead of making dog, inherit to mamal, inherit to vertebrate, inherit to animal.

it’s easier to classify things using pattern and type.
ex: dog should have animal pattern, mammal pattern, vertebrate pattern. and in some level layer we don’t care whether dog is vertebrate or not.

its easier to work with group theory, how we group things, how classification works.

for example in android, if i put streamable contract to a fragment, and send the fragment. how do i know that “streameable” is actualy a fragment without casting it?

but with pattern segregation, let say i have “interface Fragment” all i need to do is to segregate the pattern with “interface Streamable” contract

and now i have interface StreamableFragment: Fragment, Streamable

now i know that StreamableFragment is a Fragment, by pattern recognition.
But since Fragment in android is a open class im unable to do this.

And so, by using “type” as pattern declaration, we force developer to not doing open class or abstract class. but use pattern segregation instead.

I also hate open class and abstract, everybody does imo. why would we modify an object? we r not modifying a fish to become a mammal. why would we do that.

Builder-pattern can do all that. No complicated inheritance needed… Just Pattern and Builder.

this is my opinion based on code experience.

2

What is the “pattern”? “interface” is just a name, you can think that in your code “patterns” are represented as interfaces. Everybody knows what “interface” is, we are all used to that naming and again, I personally don’t even know what you mean by “pattern”.

Also, what is the change you request exactly? Split “interface” into “interface”, “pattern” and “type” which all do exactly same thing?

The rest of your post is not really related to the language, but to your code and its design. You can structure your Dog or StreamableFragment however you like. Language doesn’t force you to use abstract classes neither.

5 Likes
3

I think that your observed “ambiguity” of an interface is intentional, i.e. via an interface you specify what is available (points of usability), neither how it is used nor how exactly it is implemented. This is part of the abstraction scheme.

In your patterns, on the other hand, you want to establish how to approach the solution. If you have been working with Scala before, you may know mixins, i.e. given minimal data how do you implement part of its functionality. This can also be emulated with default method implementations in certain interfaces.

I do not understand your type. In Kotlin (at least on the JVM) you can use all interfaces, data classes and classes as abstract types, i.e. hand elements that are only restricted by these types, assign them to (mutable) variables, and operate on proper implementations (without knowing their details).

A typealias in Kotlin is the minimal version of a concrete type duplication, i.e. it is just a nickname for a concrete type. The advantage comes in refactoring, i.e. if you first start out with a typealias and later replace it by an(other) implementation. In that case, you just have to drop in the definition (and possibly the call of constructors and converters), all the other stuff remains syntactically the same.

1 Like
4

As I understand, instead of extending abstract class what you would like to do is have mixin just like in Scala.
Now the problem is how to emulate that in Kotlin.
Let’s say we have

interface WalkingAnimal {
    fun walk(){ ...impl ...}
    val limbs:Limbs
}

interface NoisyAninal {
    fun makeSomeNoize(){ ... impl ... }
    val voice:Voice
}

Now how we make

class Dog : NoisyAnimal, WalkingAnimal .

Basically this is fine, no problem because interface can have a method implementation.

Actually I would even better put the impl functionality as extensions:

interface WalkingAnimal {
    val limbs: Limbs
}

fun WalkingAnimal.walk() { ... impl ... }

As for the StreamableFragment example - I find this class questionable, because it causes inheritance over composition eventually. I never liked the way BaseActivity or BaseFragment in android are fathers extended, adding features on top of existing features every new layer. Maybe it’s possible to overcome inheritance hell with just extension functions, or extension functions separated from interface. Left alone Android stuff, because it’s legacy Java code basically.

2 Likes