Hacker News Reader

Comment by xamuel | Hacker News Reader

The author despises OOP, and I agree with him there. I would add that OOP can be particularly bad for games, because often times the OOP vocabulary clashes with the game's own vocabulary: the game itself has objects (as in, things the player can pick up and put in their inventory), the game itself has classes (as in RPG classes). It might even have factories, depending on the game.

All support for OOP would vanish overnight if people realized you can do all the important OOP stuff using C structs.

View on HN

> the game itself has objects (as in, things the player can pick up and put in their inventory), the game itself has classes (as in RPG classes). It might even have factories, depending on the game.

This makes no sense to me.

By that logic, it would be difficult for me to create a scheduling system for classes being taught in factories with OOP, which it's not.

For a program about classroom-scheduling, it would be nice if you could use "class" as a structure name. Then you could declare a function as taking a "class" as an argument. But if "class" is a reserved keyword in the language, you have to come up with some other name like "_class" or "ClassStruct".

I didn't mean to say it's an earth-shattering obstacle. Just one minor additional nitpick to add to the gigantic pile of problems caused by OOP.

The use of "clazz" by Java programmers always seemed like a good solution to me.

Clazzy. Is there a name for this design pattern when the name you wanted was already taken by a language keyword?

Most modern C++ games use an Entity Component System (ECS)

https://en.wikipedia.org/wiki/Entity_component_system

> the game itself has objects (as in, things the player can pick up and put in their inventory), the game itself has classes (as in RPG classes). It might even have factories, depending on the game.

Am I an idiot for not knowing for sure this is a joke, or is the poster an idiot for not intending a joke?

I'm so confused...

It's not intended as a joke, and please have patience with me if I'm an idiot.

Imagine you had a program involving, say, chairs. It has things called chairs, which you pass around to functions which take chair arguments. Suddenly, the next version of the language comes out and now "chair" is a reserved keyword, and all your code is broken. To fix it, you have to go through your whole codebase and rename all your "chair"s to "ChairStruct" or "_chair" or something.

I didn't say it was a major world-stopping difficulty. It's just one additional nitpick against OOP for games (added to an already gigantic stack of much bigger problems caused by OOP).

By that logic, you can’t program interrupts with C because “int” is a reserved word.

> you can do all the important OOP stuff using C structs.

Such as having a safe, leak-proof string type? I think not.

SDS is a safe, leak-proof C string implementation. Obviously you can misuse anything, but SDS is easy to use correctly. It's robust enough for Redis.

https://github.com/antirez/sds

It's considered horrendous practice to typedef to a pointer of something. Not sure why this can be considered easy.

Citation needed on that, plenty of major libraries typedef pointers all the time.

Yeah. Like I remember the win 32 API (not saying it's a good API though) to typedef every struct and it's pointer. I'm not sure if the Linux API are the same though.

I don't do much in C anymore and definitely never used a library that had a typedef'd pointer type. If I had to guess I'd imagine it's something like: variables that are pointers are syntactically different. Unless they're used "opaquly" I guess.

If I see a declaration like "Foobar baz;" I don't know which of "baz.boo", "baz->boo" or "baz[x]" are syntactically valid at a glance.

Dunno if that's a huge deal but it's all I came up with.

The thing is, even with the raw pointer the hard part is resolving ownership questions, not resolving the type. The tricky questions in C are: am I responsible for freeing it or is the library? If I send it into this function call am I transferring ownership? Type deffing doesn't make any of that easier or harder to figure out. Whether the thing is a handle or a pointer doesn't really complicate things, if that makes sense.

I get what you're saying, but I'm speculating what not type defing might help with. It's clearly advice that drifts around. Even if you think it doesn't help much it must address something for somebody, right?

GameObject, GameClass, GameFactory

Reply on news.ycombinator.com