I have a use case where I need to talk about class...

# getting-started

[Ray Rahke]

I have a use case where I need to talk about classes themselves rather than instances.
Having to do Foo::class repeatedly is kind of annoying compared to just doing Foo in languages like Typescript/Python

val relevantTypes = List<Base>(SubA::class, SubB::class, SubC::class, SubD::class)

Is there a nicer way to do this?

[Shawn]

variadically? nope. you could hack something together with inline and reified but you would need to write a function definition for each arity you need

[Shawn]

what you're describing is not all that common in Kotlin or other JVM languages, so designing the syntax around this use case wasn't a priority

[Shawn]

moreover, when you pass Foo in without qualification, it actually references the class's companion object if it exists

[Shawn]

if this kind of usage is extremely important to you, this is how you might simulate it

companions as parent classes.cpp

[Ray Rahke]

I find that I often end up passing classes themselves as data in programs where the domain im working in is abstract and very concerned with types themselves. im not sure what a better approach there is in kotlin

[Ray Rahke]

all i can think of is mapping strings / enum names to the classes

[Ray Rahke]

and that is n*2 work

[Ray Rahke]

in an entity component system, the type of component matters

[Ray Rahke]

you need to be able to ask `if component instanceof Transform``

[Shawn]

why not just if (component is Transform)?

[Ray Rahke]

new to koitlin, you are right

[Ray Rahke]

that is better

[Ray Rahke]

but that is fine when hardcoding

[Ray Rahke]

i need to pass it dynamically

[Ray Rahke]

I create Systems

[Ray Rahke]

systems need to say what components they care about

[Ray Rahke]

that is dynamic and not hardcoded

[Shawn]

we all create systems

[Ray Rahke]

the S in ECS = systems

[Shawn]

it's just a matter of finding the correct abstraction to represent them lol

[Ray Rahke]

specific term sorry lol

[Ray Rahke]

like class PhysicsSystem {
track = listOf(Transform::class, RigidBody::class)

[Ray Rahke]

so it knows only to track entities who are instances of those classes

[Ray Rahke]

or maybe something like in chess
val piece ...
fn(piece: KClassPiece) {
if piece is Piece

[Shawn]

I think the chess example is actually probably a good use case for a sealed class or maybe an enum lol

[Ray Rahke]

maybe sure

[Ray Rahke]

but i represent these things with classes already

[Ray Rahke]

like if I already have this 50 line file for a King piece

[Ray Rahke]

im not going to do also make an Enum for the King name

[Ray Rahke]

i should be able to just use the class itself as the n ame

[Ray Rahke]

map {
"King" -> King::class
}

[Ray Rahke]

this looks terrible to do

[Shawn]

I mean, it's hard to give suggestions without knowing exactly what you need, but in this case, why not just have a val name on Piece and have your classes implement it?

[Ray Rahke]

just redundancy. if the sub class name is King, having a val name = "King" is unnecessary

[Ray Rahke]

class RigidBody : Component {
val name = "RigidBody"
}
like this sucks

[Shawn]

My point is more that KClass may not be the correct abstraction for what you need, and that you may be better served more directly modeling the data required rather than relying on one that was written with entirely different goals in mind

[Ray Rahke]

im gonna have hundreds of components in my game

[Ray Rahke]

Sure but I am not aware of a better approach yet.

The fact of the matter is this is a use case where I need to be able to say "Give me a list of classes, and I will filter all instances for only the ones who are instances of those classes"

[Ray Rahke]

that should be easy to express in a language I think. it comes up a lot at least in my projects.

[Klitos Kyriacou]

This looks a bit like the "Switch Statement Code Smell". Are you sure you can't do this using proper OOP principles?

[Shawn]

If you need instances of one class you could instances.filterIsInstance<ClassImLookingFor>()

[Ray Rahke]

@Klitos Kyriacou I'm doing this to stay in line with proper OOP principles. I have an abstract base class Component which is used everywher else in my program as the interface of which you should pass in sub classes instances (so liskov + DI)

[Shawn]

if you need instances of multiple classes, you can't use this approach unless you can have them inherit from a shared type

[Ray Rahke]

sorry to be clear its composition not multi inheritance

class Entity {
val components: ListComponent
}

[Ray Rahke]

so filtering all entity instances for only the ones whos .components includes all given class types

[Shawn]

so like, are you writing an implementation or are you trying to provide like a physics DSL? like I said before, this is a tough thing to do variadically, but you can always .filter { it is Transform || it is RigidBody } at the call site

[Ray Rahke]

how do I paste kotlin code

[Ray Rahke]

Untitled.kt

Untitled.kt

[Ray Rahke]

@Shawn so I am trying to do that filter you did but it conceptually needs to be variadic

[Ray Rahke]

since the sorts of systems that might exist in your game engine are variable

[Ray Rahke]

this works right now but the syntax is

filter(entities, listOf(RigidBody::class, Transform::class, ...)

[Ray Rahke]

and i just find it a bit ugly and verbose

[Ray Rahke]

i am sure that stuff this abstract rarely comes up in mobile android dev where kotlin priorities are but this seems like a very reasonable use case

[Shawn]

I don't do mobile android dev, and this kind of thing still rarely comes up in my line of work lol

[Ray Rahke]

lol yeah it also loads on a certain style of programming for sure

[Ray Rahke]

it has came up for me in like 6 times now in multiple languages

[Ray Rahke]

because all of my apps are using heavy OOP with tons of super abstract interfaces/classes

[Ray Rahke]

that i inject everywhere variadically

[Ray Rahke]

a rust/c programmer would find my code super overly complex and alien to look at

[Ray Rahke]

i am totally open to an alternative but i have not been able to find one satisfying

[Ray Rahke]

cause like, the problem at hand just actually is about types themselves instead of instances.

[Shawn]

I actually don't think this is all that "OO" actually—in fact I think the way you're trying to encode your logic into the type system is much closer to what folks writing Haskell or F# like to do with their type systems

[Ray Rahke]

i do wish oop languages could get as semantic / type oriented as those fp languages

[Ray Rahke]

talking about types themselves during runtime

[Shawn]

you mentioned TypeScript earlier and the folks at MS working on it definitely take a lot of inspiration from or at least have a good understanding of the goals F# is trying to achieve

[Shawn]

yeah, I don't think Kotlin is getting Kinds anytime soon lol

[Shawn]

not real, first-class ones anyhow

[Ray Rahke]

yeah TS is has the most sophisticated typing feature set ive seen so far

[Ray Rahke]

but its JS and i am tired of that

[Ray Rahke]

kotlin is really pretty

[Ray Rahke]

and looks robust

[Shawn]

it's still a JVM language catering to JVM user needs, so the language designers will typically prioritize things like compiler performance/maintainability and legibility for folks used to writing Java and other OO languages over, say, making higher-order types easier to represent

[Shawn]

moreover, most of us do get by without the exact syntactic constructions you're asking for by using other approaches, even if they seem a bit verbose in comparison

[Shawn]

Scala did not prioritize those things and look where it is now

[Ray Rahke]

But the other approaches seem to compromise on these OOP principles about dependency injection and liskov substitution

[Ray Rahke]

i can't hardcode what components to filter for

[Ray Rahke]

the description of an ECS is
"you have some systems who care about some components that they use to filter entities by"

[Ray Rahke]

translating that to a computer program, its clear we gotta be passing in types themselves

[Ray Rahke]

in the abstract.

[Ray Rahke]

"Dont use dependency injection, make your programming more concrete and have less abstraction layers" sounds like the only alternative

[Shawn]

Well, your original example is still hard-coding the types you need, right?

[Ray Rahke]

you hardcode what types each System needs, sure

[Ray Rahke]

but you can make new systems at any point

[Ray Rahke]

Untitled.cpp

Untitled.cpp

[Ray Rahke]

those systems then get integrated into the game engine

[Ray Rahke]

and all the game engine code talks about systems in terms of the base interface. DI+liskov substitution going on.

[Ray Rahke]

cause thats how the game engine needs to work to be extensible for new features. let people make their own systems that track whatever components they want, and then just plug-and-play it into the engine.

[Shawn]

admittedly, this is a bit harder if we're talking about providing an engine for others to consumer and plug into, but I guess the best way to do it probably depends on the details how your pipeline actually works

[Shawn]

to me it kinda seems like `Component`s are being passed to systems kinda like a message queue, and each individual system wants to subscribe to specific queues (i.e. types of messages/components)

[Ray Rahke]

@Shawn yeah kinda. but its not event based. every frame of the game, the system goes through and updates every entity who has the components it cares about

[Ray Rahke]

so a PhysicsSystem will go through every entity with a RigidBody component, and perform some operation like accelerating the velocity downwards for gravity etc.

[Ray Rahke]

every frame

[Paul Griffith]

yeah, there’s no way to do a trackN extension function or anything to (abuse) reified types to get arbitrary resolution. You could manually write out the first few overloads, but they have to have different names for overload resolution, even in Kotlin, so it’s still a pretty awkward UX

Untitled