a good class - part 2
note: this is part 2 in a series of posts about oop. part 1
i asked claude what he thought about my previous article and…
now, the good thing with ai roasting is that it cannot quit the conversation. you can continue to trade blows. and i did.
what i learned
it’s simple:
there are no good classes.
i tried saving the idea as hard as i could, but all my points were moot.
immutability? you don’t get that. not with python.
even with frozen, if your class has a list, won’t work…
the read() function?
it’s an overcomplicated setter.
the real “message passing” should be done by a system
(more on that later).
slots won’t improve your control over your data structure,
hot data, block size:
you’re better off with an array…
last but not least: the property check?
yeah but why would you want that?
why would you want to give up on the ability to freely compose data whenever you want, whenever you need?
in other words…
data is just data
and it belongs in a database.
not in a class, in a database.
your code shouldn’t have state and your data shouldn’t have behaviors.
or as they say in the video overwatch architecture:
systems have no state, components have no behavior
this is the root of entity component system, or ecs in short.
e-c-s, baby
the best video you’re going to see about ecs is this one. please watch it.
i mentioned the array library earlier. because i love python, and i try to write python as a c wrapper as much as possible.
and i’m not gonna ruin it by writing classes, no no no.
so what is ecs?
in one sentence:
a struct of arrays instead of an array of structs
in one picture:
don’t write vertical “classes”. write horizontal “data slices”.
easier to store, easier to load, and paradoxically, easier to reason about.
if it didn’t click for you, more homework:
the last nail in oop’s coffin
i’ll leave you now with one very important quote.
while trying to argue that classes could work for some use cases with delaney (who’s way nicer than claude, surprisingly), i tried the:
what if you only need it once? just once! for fixed parameters! we have tools for that, but what should we use? enums, named tuples? dataclass with frozen and slots?
and the master said:
if you think you’re gonna need it once, you’re wrong.
and the student was enlightened.
start with an array of length 1. it’s gonna become 2 soon enough.
input control? you’re gonna netcode it. config file? you’re gonna have a test environment. camera system? what about a killcam?
it’s arrays all the way down.
so start with them. then you’ll build structs. of arrays.
not arrays of structs.
oop feels organized. to you.
but to your cpu? not that much.
before we dive into practical ecs, a little detour in the next post.
next up: orm.