What do you think about class-based OOP vs. Prototype-based OOP?
I think that class-based OOP is an unnecessary abstraction of structs, functions and global variables most of the time.

Well for one, prototyping has the issues of dynamic typing in general: correctness, maintainability, and performance.

Classes make sense when data and behaviour are closely coupled, e.g. for data structures like stacks. You just don't need a stack where one instance also can sell banana and another can wash your car.

However, none of the variants captures what Alan Kay actually meant when he coined the term OOP, and that's actors passing around messages over defined interfaces.

FP ftw.

@Fast-Nop So if you code things to trigger events that other actors can subscribe t and act upon, that would fit the original meaning of OOP?

@Fast-Nop
There are statically typed Prototype-based OOP languages.
Two of the most popular entries being Go and Rust.

@Cultist not suitable for a wide range of real world problems. Especially any time manipulating state or behaviour is the whole point of the program, not calculating results from data.

@kescherRant that's event based programming, but if you want to have that both ways, you quickly end up in a callback hell because you end up with n^2 connections.

Instead, you can have e.g. something alike to a postal system where each actor sends messages to the postmaster that contain whom he wants to send to, and each actor has some inbox where he receives messages. That leads to a star topology with only n connections.

This way, you can just send an answer to whoever was the sender of the message, and the actors don't really know each other.

@metamourge but of what static type is an object that you extend at runtime?

@Fast-Nop
They don't exist,
In Go, the data type that comes closest to traditional objects would be a struct, and the fields of structs are defined at compiletime,
Essential same behavior as in C.
Prototype-based OOP doesn't need to be dynamic bullshit ala JS and Python.

Trait based programming is my favorite way to do interfaces so far... really dislike inheritance since it's easy to abuse.

@metamourge but if types don't even exist, how can they be static? Or do you mean that the other way around, that you can compose an object, but if you then try to use some property that it just doesn't have, the compiler will refuse to compile that?

(Because composing an object is distinct from using it, unlike JS where just assigning a value to a property creates that property if necessary)

@Fast-Nop
I was talking about runtime-extendable-types.
They don't exist.
Types in Go work pretty much as in C, so everything needs to have a type.
And you can't add or remove fields from structs at runtime.

The original purpose of classes is to allow mapping of the object to pointers into a comprehensive and known length piece of memory.

Both have their pros and cons but I prefer class based.

But both can make spaghetti if not handled correctly. And OOP programming is actually language agnostic, its more a way to design programs.

Some languages have built in structures to help, others don’t, but even in a language without you can still build programs using OOP its just more boilerplate to do.

Prototype based, in my opinion, are good for small projects, but once the grow, and you have 20-30+ developers, you have to either have a very strong structure and good communication or you might end up with multiple implementations very similar but not really compatible.

And that means more code that can contain bugs or that needs updating when something changes.

Classes and interfaces can help, but are no guarantee.

It's about the future, if you want to be done once and for all, prototype then.
But if you will improve it in the long run, there's no excuse, abstractions and layers will keep mind sane the more the project becomes complex

@h4xx3r
Why?
I know JS has a shitty implementation of OOP but, eg. Go has a pretty neat implementation of Prototype-based OOP.
You even get composition with automatic field- and method-overrides, which makes it nearly feel like Inheritance, while not being inheritance.

@metamourge I'm not sure how this does apply to Go sincerely, never desired with it.

@Cultist you can do both OOP and FP at the same time