>>107016260
Who says inheritance is bad? It's (probably) a tool in your toolbox. You wouldn't reach for a screwdriver if you needed to hammer a nail.

>>107016282
there (at least) more than 500 people who says that inheritance is the root of all evil, and that OOP is this and that (which i agree with to some extent) and all that shit, it's hard to find a reasonable take on when and when not to use such a thing

>>107016260
learn about composition, then ECS

abstraction is literally the only pillar of OOP that is good. inheritance is the biggest cause of confusing and over-engineered code

>>107016303
Don't get me wrong, I fucking detest how ritualistic OOP is in general. But anti-OOP can become just as ritualistic. I think that if using prototypes and inheritance leads to structure that's more elegant and easier to write and maintain (even just for future-you in six months) then it makes more sense to just use it the way that makes sense instead of... ritualistically avoiding it due to your priors. Not YOU you, but you get what I mean.

>>107016282
The reason why these counter mainstream ideas happen is because the masses use it and the masses aren't necessarily smart.

>>107016260
The main reason inheritance has a bad reputation is because most people that use it are retarded and make absolutely everything a class when it really shouldn't be. It's a tool like any other, it has it's uses, you have to learn when to use it or when not to.

>>107017441
because java.

File: 1761069958776750.png (522 KB, 720x769)

522 KB PNG

>>107016260
yes. Use functional programming instead.

File: 1758373800279140.jpg (42 KB, 350x490)

42 KB JPG

>>107016260
Singular inheritance is ok (it's basically a cast), but obviously multiple inheritance incurs a lookup penalty

>>107016260
>objects with physics, object who are enemies, etc, who have a lot of stuff in common
it's difficult to describe how stupid typing something like this make you look. do you in fact believe that it's enough to "inherit physics" and "it's called an object, so it exists in a world"?
objects, in context of programming, encapsulate their state. if a programming object, that represents a physical object, decides to change its state and in essence represent a physical movement to another location it HAS TO FUCKING ANNOUNCE IT TO THE REST OF THE PROGRAMMING OBJECTS. do you realize how retarded that is?
ecs sort of sidesteps this and reduces the retardation levels by allowing objects to essentially own objects from external sets where a sensible algorithm can do its job over all data in bulk (breaking encapsulation).
go grow beets, computers are not for you.

>>107017890
you seem really angry and you are not making sense either

>>107017952
he's an ECSfag. they're the only ones more insufferable than OOPfags.

>>107016303
Those people are retarded.

>>107016260
Extending one (abstract) class is fine in most cases and that stuff makes sense if you need some base functionality and little customization for the concrete implementations. Where it gets weird is when there are huge inheritance chains where you're forced to shoehorn behavior into that you don't even want because you suddenly habe to implement more methods/behaviors than you need or even make sense.

Also there's the retardation of being able to inherit from multiple separate classes but that's python retardation and even them everyone tells you not to do it

I've been doing some work on space station 13 after doing a bit of space station 14.

Space station 13 uses inheritance, space station 14 uses ECS.

I find that when I'm using a great deal of inheritance I find myself yearning for ECS because it lets you sort of just add functionality to any one entity, whereas with inheritance you kind of have to deal with That Which Pertains to the Thing you're adding and everything else it inherits.

I'd say that my experience is that you use ECS when you're making something where a """Thing""" might end up being very different from another """Doohickey""" but you might occasionally want to make the """Thing""" and """Doohickey""" reuse the same code for a reason or another.

Easiest example would be slapping a "PowerConsumerComponent" onto a flashlight and a refrigerator.

One's a stationary piece of furniture. The other's an item you'll probably carry around with you. They both consume power but don't necessarily inherit from one another, thus making it handy to use ECS so that you don't have to create a BasePowerConsumingFurniture and a BasePowerConsumingItem class.

That's my perspective at least. Rubber ducking this onto you also made me realize why only games that tend to be rather complex tend to use ECS...

>>107016303
just don't use inheritance for classification

>>107016539
>how ritualistic OOP is in general
elaborate

>>107017441
is your biggest problem really just having to define a function inside a class?
how is that exactly a problem? and how is that related to inheritance?

>>107018627
that's an example of misunderstanding how to properly use inheritance - you're trying to apply it to a problem where inheritance doesn't fit to make a point that inheritance is bad

for that kind of modularity you should either use composition, or some design pattern like the Decorator

>>107016515
Based and underrated. And I'm not even joking. Only use inheritance if it's the only option for your design. Otherwise, make any inheritance as shallow inheritance. Deep inheritance trees are an indicator mindless use of this language feature.

>>107018747
>just don't use inheritance for classification
what to use them?

>>107018795
depending on the context, either make it a property of the instance, or map it outside of the instance

>>107016260
composition covers these

>>107018747
>is your biggest problem really just having to define a function inside a class?
not mine, I'm speaking in a general sense
>how is that exactly a problem
it's just kind of stupid, functions are inherently reusable and arguments exist for a reason
>and how is that related to inheritance?
it's not, but people love generalizing.
>this stupid thing is commonplace for beginners in oop, so oop is completely worthless, I'm so smart
I personally avoid classes as much as I can because I started off with an imperative approach and everything just makes way more sense in my head when it's either imperative or functional, but I've had to work with classes a fair bit too and I'm not gonna try to act like you can't get anything done in OOP the way most elite haxx0rs do

>>107017890
ecs is as retarded as OOP, it has the same issues, you always end up writing a convoluted event system so things can cross talk just like you do with OOP.


>>107016260
Yes and no but objectively yes. C++, C# and Java's implemention of it is retarded. This is simply because of initialisation and destruction bullshittery.

If it was done right it wouldn't give the user the option to choose what happens to the parent object, it would just automatically call the parent's constuctor and destructor. Also constructor Overloading should never be a thing. It's the root of all evil.

>>107019041
>not mine, I'm speaking in a general sense
pointless, then

>I personally avoid classes as much as I can because I started off with an imperative approach and everything just makes way more sense in my head when it's either imperative or functional, but I've had to work with classes a fair bit too and I'm not gonna try to act like you can't get anything done in OOP the way most elite haxx0rs do
first, for accuracy: procedural and object-oriented are both imperative paradigms (ie. you write instructions _how_ to get the result) while functional is a declarative paradigm (ie. you write _what_ to get as the result)

second, the main difference between procedural and object-oriented programming is in OOP you organize state and behavior in smaller, coherent contexts that can communicate with each other. the main difficulty for someone already used to procedural programming is defining those contexts, which you only really learn from experience. small contexts make code easier to understand and maintain, especially in large projects
eg. to someone doing procedural programming, max() and avg() would obviously be just some functions that take some collection of numbers as an argument and spit out the result;
in OOP, that collection of numbers could be a class with max() and avg() as methods. this has some advantages over a purely procedural approach, like needing less arguments for the functions, keeping the state consistent within an instance of the class, hiding fields and functions that are "internal" in order to provide a cleaner interface for some logic, and so on

>>107016260
>1: if im making a game, and objects with physics, object who are enemies, etc, who have a lot of stuff in common (having X and Y possitions, having speed, collision, maybe health, etc
>2: if im making a config menu and a lot of entries have the same parameters (having tooltips, labels, default values, etc), in this case there would be a main one (with universal values that apply to each one) and sub-categories for each type of config (if its its a number, a name, value, or even file)
Neither of these are Inheritance.
Inheritance is an *abstraction* - if you want to test if something is OOP or not, just do the C-test.
Can I do this in C with structs? If the answer is "yes" then it is not OOP.
Abstraction means, embedding your stuctured data into the type-system. But that is not enough! C has typdef structs!
You need a syntax, like classes. And you also need, crucically, METHODS.
This is where "inheritance" becomes dogshit, you end up hauling around more than just data. You carry around dispatched "generic" functions. Which leads to bloat.
Notice how all your so-called "good examples" pertain to data, and not functions?

Inheritance is just poor man's generics, which is why the debate centers around OOP vs. FP.
Instead, you want a TRUE generic function, with templates, or with overloading, etc.
With standalone functions, you could wrap them into a separate library, with minimal duplication.
True generic functions are the answer. Not wrapping the functions with the data.

>>107017952
everything in oop is a misnomer. for every instance of "class" replace it with a "rdbm table" and "object" with "rdbm table row". except it is a retarded rdbm and you can't access anything directly.

SELECT x, y, z FROM knives

is not allowed, because it goes against the oop commandments. what you must do instead is

SELECT compute_location() FROM knives

.
now do you see how unfit for anything oop is? you can't operate on data, you can't do joins, if you share objects you once again break encapsulation and might as well throw everything out. yet people do this anyway, and they end up with pure shit in code form.
>>107017959
ecs is oop with some cope carve-outs for where it's obvious that performance suffers. so it's fake oop. is that better or worse, you decide.

First fucking time I'm hearing this.
It's a common and useful technique in OOP and you are expected to use. It's hardly optional.
The real can of worms is whether you should even bother with OOP. But if you do then yes. It's weird to see OOP code without any form of polymorphism.

>>107020019
>>107020430
outright wrong understanding of what objects and classes are
of course it won't work for you if you don't understand the most basic principles of it

>>107016260
Just use a pointer.

>>107016260
>is inheritance that bad?
It's like GOTO; it doesn't have to be bad, but it can be bad and because it can be bad it will be bad.

>objects with physics, object...have a lot of stuff in common
You want protocols/interfaces/traits/etc. This is a dependency of the called function, not the supplied object, and it should be treated as such.

>if im making a config menu and a lot of entries have the same parameters
Have a function that takes an interface and creates and attaches these.

File: scamble vice 24243342.png (156 KB, 2560x2880)

156 KB PNG

>>107016260
Inheritance is bad because objects are bad.

>>107020618
are you gonna explain anything or are you gonna go extend a cat to a dog as a cope?

>>107020845
not worth the effort, cniles are irredeemable midwits incapable of abstract thought

>>107020958
i accept your concession, zookeeper

>>107020464
inheritance (specifically class inheritance) isn't the only form of polymorphism
interfaces are generally better

>>107016260
>if im making a game, and objects with physics, object who are enemies, etc, who have a lot of stuff in common (having X and Y possitions, having speed, collision, maybe health, etc
This is what an entity component system is designed to solve, while being less complex than inheritance
The idea is you have only one type of object (an entity) and nothing inherits from it. Instead you add tags (components) to entities that modularly define what they are (like whether they have health, whether they are controlled by AI, whether they are able to be picked up, etc.) and a game loop iterates through all entities in the game and does things to them based on those tags.

>>107018747
>elaborate
I mean it more from an organizational standpoint. A ritual, crystallized, is an action undertaken under some kind of a priori framework. A ritual is dogmatic and often occurs regardless of how much sense it makes under any other framework. I'm probably overcomplicating it, but OOP is a dogmatic precondition under many organizations. It's not a methodology but an organizing principle which must be obeyed without question. It's the danger of programming paradigms in general, I think: any unifying framework will lose precision in the process of unification and often introduce new inefficiencies for every inefficiency it (often imperfectly) solves.

>>107021438
did you prompt an AI to generate this drivel?

>>107016260
anything with more than 1 layer of hierarchy is AIDS

>>107016260
it makes you lazy to get a job

>>107019335
>small contexts make code easier to understand and maintain, especially in large projects
people always parrot this dumb shit but it is so obserably not true in practice. dividing everything into tiny pieces makes flow control harder to follow and your brain has to keep track of way more call stack in a way you simply wouldn’t have to if you just wrote longer functions. i think it’s just stupid to intentionally make everything small. if i see a common use pattern form from something i’m now finding mysef writing more than once then yeah, ill break it out into its own function but doing it as a force of habit to literally everything just because is just not a good idea. i’d much, much rather be looking at a 500 line function than 100 5 line functions and it isn’t even close. long functuins also have more predictable compiler output whereas with a million inline functions you just have to hope it does the right thing or in a worst case undo the work you did to put the code in a separate function and copy paste it back in to a bigger one anyway

>>107016260
The only language where inheritance from concrete types is actually useful is Common Lisp, because it avoids the retardation that almost every other language does: bundle data types and functions together.

Inheriting purely abstract types such as Java interfaces is also OK. In every other case, inheritance causes more trouble than it's worth and it's better avoided.

OOP is just Platonism for autists.

>>107016260
3: when a man and a woman love each other very much...

>>107021859
>but it is so obserably not true in practice
skill issue

>dividing everything into tiny pieces makes flow control harder to follow and your brain has to keep track of way more call stack in a way you simply wouldn’t have to if you just wrote longer functions.
your problem lies in assuming you need to memorize the whole flow and call stack for whatever you're working on
the point of building abstractions and splitting things into smaller contexts is to reduce the required cognitive load: instead of keeping track of everything, you focus just on the relevant context
if I were to have a program that processes images and I need to fix something specific to decoding JPEGs, I would only need to touch the class/method responsible for decoding JPEGs; I wouldn't have to even look at the parts before (eg. finding/downloading the file before decoding) or after (eg. processing the decoded image data)

>long functuins also have more predictable compiler output whereas with a million inline functions you just have to hope it does the right thing or in a worst case undo the work you did to put the code in a separate function and copy paste it back in to a bigger one anyway
that's an implementation/build environment problem and not an abstraction problem

>>107020019
holy shit
how do you manage to dress yourself without grievous bodily injury?

File: 1760726593237618.jpg (456 KB, 1600x1170)

456 KB JPG

>>107016260
std::variant >>> std::unique_pointer<base_class>

1: if im making a game, and objects with physics, object who are enemies, etc, who have a lot of stuff in common (having X and Y possitions, having speed, collision, maybe health, etc

just have those as member variables dog. struct Player { Health health; Collider collider; };
it's literally what inheritance doing internally anyway

2: if im making a config menu and a lot of entries have the same parameters
using Parse_Entry = std::variant<Tooltip, Label, std::string, float>
std::vector<Parse_Entry> parse_ini_file(std::string_view);

the ONLY time you would use polymorphism and inheritance is when interfacing with a dynamic library and you don't know statically what the code is. if it's in your code base, it shouldn't be polymorphic

>>107022562
>Player { Health health; Collider collider; };
Alright, and how will this work in practice, exactly? Mainly the collider part, health will clearly be a setter/getter pair, so a meaningless variable holder.

File: 1757464690366950.jpg (111 KB, 739x894)

111 KB JPG

>>107016482
>>107017890
>>107017959
>>107018627
ecs is dumb because it obscures the true type of something and if you believe in ecs you're dumb. like struct Player, struct Enemy, ends up only existing in the programmers head and in the code its a collection of components.

just do

struct Game_State {. 
   std::vector<Player> players;
   std::vector<Enemy> enemies;
   std::vector<Lights> lights;
   std::vector<Camera> cameras;
};

extern void each(std::function<void(Health, Transform)> foreach_comp_lambda);

// statically call on appropriate types
void each(std::function<void(Health, Transform)> foreach_comp_lambda) { 
   for(auto& ply : game_state.players)
      foreach_comp_call(ply.health, ply.position);

   for(auto& enemy : game_state.enemies)
      foreach_comp_call(enemy.health, enemy.position);
}


// works with inheritance, composition, interfaces, etc. unlike ecs
// complete picture of the final type written in code, static component query lookup
extern void each(std::function<void(IOnEnterGame*)>()));

unfortunately c++ reflection only comes in 26 so it's ugly for now having to implement manually each permutation of the 'each' call, with macros or templates

>>107016260
I "had to" make a custom GUI framework for a personal project I was making (C++) and while I normally try to avoid OOP, it makes it extremely clean and easily usable. Much better and more dynamic than functional cancer with invisible states, like ImGui.
I think people that instinctively hate OOP are under the impression that others want to forcibly use it in every scenario, when it's more of a situational tool that could be useful to solve specific problems. To be fair to them, that is how universities portray it.

>>107016260
Inheritance is usually always wrong because its based on encapsulating data and not encapsulating interfaces. If you want to try OO done right out of the box then try multiple dispatch in Julia

>>107016260
I've got a question for everyone here, why interfaces instead of abstract classes? most if not all use cases for interfaces could be accomplished by abstract classes and those give a more clear, rigid and robust design for the codebases

>>107023019
https://www.youtube.com/watch?v=kc9HwsxE1OY

>>107023019
because with interfaces you know that there isn't any hidden logic. they just declare the functions that the class has to implement.
it's way cleaner especially if you work on someone else's code or some huge codebase

>>107016260
Inheritance is good but you have to do it the right way like Common Lisp.

>>107023048
But if you have hidden logic in your abstracts thats poor design on you, abstracts should be clear and single purpose

I come from corporate Java and C# software. It is evil there. You get these people doing abstraction inside abstraction inside abstraction. It’s essentially the hardest shit to debug or maintain because they throw so much magic into it. If you’re using simple composition you get essentially a list of the functionality inside the actual class you’re working on such that you know that this class has logging or whatever. One level of inheritance might seem not bad, but it’s impossible to tell if it’s one level or a thousand without clicking through to each subclass.

reactshiter here. whats going on in this thread?

>>107023019
I can just have one (abstract) superclass, vs I can implement multiple interfaces

oop is bad because it's fucking terrible to keep track off the control flow of your program when it's creating a billion instances of classes combined with classes said class inherits from which means for any given point of your code base you have to have hundreds of tabs open in your editor just to see where the fucking data is flowing and how its being manipulated. If your code doesn't read like a cooking recipe then you have fucked up. >inb4 jeets screaming about muh java sir, that's not oop, this is my pet oop definition
Get fucked. OOP is inheritance, strip that from oop then you're programming in C with extra bullshit steps.

There's a little dog living in my computer :) The dog is an animal!

>>107024395
>wraps a simple function with a class in your path
java is a cancer

>>107025505
Is your classpath properly configured THOUGH?

>>107024378
Yeah why would i want multiple interfaces if they serve the same general purpose and I'll be using the same interfaces multiple times? I don't see the abstract superclass as a flaw

>>107025728
a class can be, idk, decodable and previewable (or whatever), but there are classes that are only one of these. how would you do that with abstract classes?

>>107016260
It's fine, it's just a way more specific thing than C++-like OOP languages make it seem. You need it far less often than you might think.

>>107016260
Any decent programmer knows that inheritance is fucking stupid. Have you considered being a no-coder instead? It would fit your brain better.

>>107022670
>ecs is dumb because it obscures the true type of something
No. You just don't understand what programming is: data transformations. An ECS will allow you to focus everything on transforming data instead of having to pretend that the important part is some abstract object that the processor should never need to worry about.

I don't mind OOP in general, I just hate niggerlicious code that decides everything must submit to the OOP design even if functional or procedural would work 10x better.
There is a limit of the number of abstractions you can do before things become bloated and more complicated, where backtracing the functionality of a method of an object with several iterations of inheritance becomes more of a pain than it is worth.

>>107022254
>assuming you need to memorize the whole flow and call stack for whatever you're working on
because you do. that’s how you understand what something is doing. whether it’s debugging or just learning a new codebase, small functions just make things harder. you end up having to track more bullshit in your head and that alone puts a price tag on the abstraction

>I wouldn't have to even look at the parts before
in fantasy land that may be true. the reality is you’ll go in assuming your decoder is broken only to find some subtle bug coming from earlier that causes the image data you’re receiving to be corrupted. even just confirming something works the way you think it does by stepping through the debugger is a nightmare in OOP between tiny function retards forcing you to jump around everywhere, implicitly running constructors and destructors everywhere, inheritance hierarchy vtables and exceptions.

>that's an implementation/build environment problem and not an abstraction problem
a pointless distinction. reality is reality. we work off the power of compilers, not imagination.

>>107026479
it's literally the same, continuous arrays of data. at least this way you can see and access the entire entity directly and have static checks and don't have runtime costs of query lookup and you can have callbacks for evens that see the whole objects, i.e. OnLoadLevel, OnLoseConnection, OnPlayerJoin, OnChangeName. you don't have independent components like struct Enemy_Component { int damage; }; if its Enemy { int damage; Transform transform; }; it's always passed as one package and it exists the way the programmer meant it to exist, not some runtime amalgamation with registry.emplace / entity_manager.add_component

>>107027268
the semantics of always calling get_component(entity) and void do_someting_to_specific_player(Entity entity); is just incredibly ugly and lacks any kinds of type checks because the archetype of the entity doesn't exist in code and instead you're just working of a mental map you have in your mind 90% of the time. how many times do you even have more than 20 of a given entity? this whole paradigm is just incredibly false, why do people buy that shit.

>>107027268
What are cache misses?
>>107027494
>how many times do you even have more than 20 of a given entity?
Many, many times. Depending on what game you're making of course. I have 50000 entities running stable at 250 FPS.
And no, I don't call any "get_component(entity)" function, I just transform data. That's it. I don't need to keep a mental map of anything, all I need to do is specify what properties a given entity has, load it, and let that fucker run loose. Everything is taking care of itself.
I've written my own ECS, not using anybody elses. Don't even know if it can be called an ECS, don't care.

>>107023443
Oh yeah? But are those abstractions of abstractions of abstractions in turn abstracted? If not, check mate christ cucks!

>>107028488
>What are cache misses?
its direct calls. you iterate over the vector, there are no virtual calls. just without the component runtime archetype get_component opaque entity type nonsense

>>107016260
Yes. It's worse than Hitler.

>>107028527
You iterate over a vector filled with useless shit not needed for your transformation. Say you want to update positions of all entities. Still you load healths, damages, different states, whatever you may have specified in your struct, all not needed for updating the positions.

>>107028562
don't project your skill issue onto us

>>107021878
OOP is just materialization for hylics.

>>107028789
It is not a skill issue, you tard. It is literally what you're doing. You do understand how memory works, right?

>>107016303
With Scala you can have both

>>107016260
Call me crazy but I don't think the two examples need inheritance and for 2. I even think it's a bad usage. Most of this can just be handled by composition and factory functions, only making the similarity explicit during construction but not during rest of the instance's lifetime.

>>107031951
I'll call you crazy for implying that inheritance isnt always a stupid fucking idea perpetuated by mid programmers and university shut-ins who only theorize about coding

>>107016260
>class Anon(Player, Attackable, Movable, Retarded, Smellable, Baldable, Dickcutoffable, *100 more parents*)
>it's fine, bro

>>107033865
Just make a single entity abstract instead of all those niggerlicous interfaces

>>107033919
I have no idea if this is satire or not

>>107033919
But anon, what if there's a Fox class that is not player, is movable, not retarded, not smellable (you are not a pervert right?), not baldable, and not does not cut off its dick? You would not repeat those 10 lines of code, right? You DO apply DRY religiously, right?

I think it all comes down to how understandable the code is.
Don't use features just because they exist, don't use them just because some dogma says so.

>>107034954
You recruiter and, if you are lucky, manager don't think so

File: carlos.jpg (19 KB, 554x554)

19 KB JPG

It's not that bad if you inherit a 12 inch cock

>>107035035
What they want and what is good aren't the same and is a completely separate issue.

>>107023019
>most if not all use cases for interfaces could be accomplished by abstract classes
Why do you think this is a good thing?

Abstract classes are just interfaces with optional inheritance.
It's like a creature with a large mutated appendage growing out of its head and you're telling me: "It can use that like a spoon!"

Providing functionality that isn't needed is the exact opposite of "clear, rigid and robust"

>>107016260
I think the use of really deep inheritance causes (mostly really bad conceptual) problems, but there are certainly cases where it's the best thing to use. But those are probably extreme edge cases in practice

>>107016260
The simple answer is: just don't. Especially for game-dev, where it is arguably most abused. If you're ever using OOP for code reuse, you've fucked up royally.

There is a nice free book on Data-Oriented Design, not hard to find, check it out. Also, keep away from people that propose ECS, its just as bad.

>>107016303
OOP is great. Inheritance is trash.

>>107037566
oop is a great way to waste time bikeshedding how to arrange your class zoo

File: bb17fc97-5cd7-4dc9-b513-9(...).png (206 KB, 1280x787)

206 KB PNG

>>107036198
>like a creature with a large mutated appendage growing out of its head
it's called a trunk, dumbass

>>107037548
You have no idea what you are talking about and is most likely a beginner

>>107016260
What you describe are just two cases of the same thing: subtyping.
>i can't find good alternatives
Speaking only of things in type systems: Interfaces, type families, kinds, a structural type system with row polymorphism, etc. Anything that allows you to define an open set of types.
Why these over inheritance? Let's start out with the fact that inheritance isn't even a formally defined concept. How it works in one language and the operations supported there is completely removed from a different language. Both can claim to have inheritance though, and they are both right, because there is no formal definition of the idea. Many a person has been burned by C++'s object slicing, for a concrete example. C++ is a great example in general, because inheritance might actually be one of the worst facets of the language.

>>107037872
I was a beginner back when I used OOP. I grew out of it when I got better. OOP uniquely solves no problems. I haven't touched it in years and have never missed it.

>>107037566
what exactly do you think OOP is?