Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Fifty Shades of OOP

lesleylai.info

Post reply on HN
Print view View original

61–70 of 119 posts

Re: Fifty Shades of OOP

#61

Post by javcasas »

marcosdumay wrote: post #16
ejflick wrote: post #8

Earlier quoted context omitted.

> Basically your objects are data-only, so there's no benefit. This makes me wonder why most of us use Java at all. In your typical web app project, classes just feel like either: 1) Data structures. This I suspect is a result of ORM's not really being ORM's but actually "Structural Relational Mappers". - or - 2) Namespaces to dump functions. These are your run-of-the-mill "utils" classes or "service" classes, etc. T…

> why most of us use Java at all Java was the first popular language to push static analysis for correctness. It was the "if it compiles, it runs" language of its day, what meant that managers could hire a couple of bad developers by mistake and it wouldn't destroy the entire team's productivity. I'm not sure that position lasted for even 5 years. But it had a very unique and relevant value proposition at the time.

OCaml would like to have a word with you. In 2005 it already had better static analysis and correctness on object oriented stuff than what Java struggles to approach today.

But Java has better marketing.

Re: Fifty Shades of OOP

#62

Post by jillesvangurp »

Rochus wrote: post #12

> The industry and the academy have used the term “object-oriented” to mean so many different things. I think we can safely stick to how IEEE defines OOP: the combination of three main features: 1) encapsulation of data and code 2) inheritance and late binding 3) dynamic object generation (from https://ethw.org/Milestones:Object-Oriented_Programming,_196... ). The article assumes that C++, Java, and Smalltalk impleme…

The problem with that definition is that modern languages like Rust, Go, and Javascript fall between the cracks here with de-emphasizing things like classes and inheritance while still providing things like generics, interfaces, encapsulation, etc.

For example, Javascript was influenced by a few languages, one of which was a language called Self which is a Smalltalk like language where instead of instantiating classes you clone existing objects. It's a prototype based language. So, there weren't any classes for a long time in Javascript. Which is why there are these weird class like module conventions where you create an object with functions inside that you expose. Later versions of ECMA script add classes as syntactic sugar for that. And Typescript does the same. But it's all prototypes underneath.

Go has this notion of structs that implement interfaces implicitly via duck typing. So you don't have to explicitly implement the interface but you can treat an object as if it implemented the interface simply if it full fills the contract provided by that interface. Are they objects? Maybe, maybe not. No object identity. Unless you consider a pointer/memory reference as an identifier.

Rust has traits and other constructs. So it definitely has a notion of encapsulation, polymorphism, etc., which are things associated with OOP. But things like classes are not part of Rust and inheritance is not a thing. It also does not have object identity because it emphasizes things like immutability and ownership.

Many modern languages have some notion of objects though. Many of the languages that have classes tend to discourage inheritance. E.g. Kotlin's classes are closed by default (you can't extend them). The narrow IEEE definition is at this point a bit dated and reflects the early thinking in the sixties and seventies on OOP. A lot has happened since then.

I don't think a lot of these discussions are that productive because they conflate a lot of concepts and dumb things down too much. A lot of it boils down to "I heard that inheritance is bad because 'inject reasons' and therefore language X sucks". That's maybe a bit harsh on some languages that are very widely used at this point.

Re: Fifty Shades of OOP

#63

Post by lukan »

ffsm8 wrote: post #59
lukan wrote: post #45

Earlier quoted context omitted.

Out of curiosity, when you say you don't like inheritance, does that mean you never use it at all, or you only use it rarely? Because even though inheritance often is used in a wrong way, there are definitely cases, where it is the clearest pattern in my opinion. Like graphic libary things. E.g. everything on the screen is a DisplayObject. Simple Textfields and Images inherit directly from DisplayObject. Layoutcontai…

> I don't see how it could be expressed in a different way without loosing that clarity. What value does the inheritance provide here? Can't you just use a flat interface per usecase without inheritance and it will work simpler with less mental overhead keeping the hierarchy in mind? Explicitly your graphic library sounds should be fine to have the interface DisplayObject which you can then add default implementation…

That would be way, way more verbose for everything.

Every display object has a x y width and height for example. And there is basic validating for every object. Now a validate method can be conposited. But variables? Also the validating, there is some base validating every object share (called wih super) and the specific validating (or rendering) is done down in the subclasses.

And even for simple things, you can composite a extra object, but then you cannot do a.x = b.x * 2 anymore, but would have to do a.po.x = b.po.x * 2 etc

Re: Fifty Shades of OOP

#64

Post by elric »

javcasas wrote: post #57
elric wrote: post #54

Earlier quoted context omitted.

Permissions.transfer(x, y, z) I'm not sure why having a global function by the same would make this any easier or harder to implement. But it would pollute the global namespace with highly specific operations.

And now you have invented a helper class when all you needed is a namespace. And you already had namespaces.

It doesn't have to be a class. It can be an interface. And regardless of what it is, it has to go somewhere. Whether it's in assorted_functions.c or Permissions.java makes little difference.

I mean it makes sense to group "like" things together. Whether that's in a module, a class, an interface, or a namespace. Having a huge number of things globally is just confusing pollution.

Re: Fifty Shades of OOP

#65

Post by Rochus »

jillesvangurp wrote: post #62
Rochus wrote: post #12

> The industry and the academy have used the term “object-oriented” to mean so many different things. I think we can safely stick to how IEEE defines OOP: the combination of three main features: 1) encapsulation of data and code 2) inheritance and late binding 3) dynamic object generation (from https://ethw.org/Milestones:Object-Oriented_Programming,_196... ). The article assumes that C++, Java, and Smalltalk impleme…

The problem with that definition is that modern languages like Rust, Go, and Javascript fall between the cracks here with de-emphasizing things like classes and inheritance while still providing things like generics, interfaces, encapsulation, etc. For example, Javascript was influenced by a few languages, one of which was a language called Self which is a Smalltalk like language where instead of instantiating classe…

Well, C++ also has higher-order functions and lambda expressions, and yet we don't call it a functional programming language.

Re: Fifty Shades of OOP

#66

Post by 21asdffdsa12 »

ChrisMarshallNY wrote: post #11
vjvjvjvjghv wrote: post #10

Earlier quoted context omitted.

I think the biggest mistake was to teach inheritance as a main feature of OOP. I have done some stuff with inheritance but it was very specialized and it would have been fine without inheritance.

Back in the day, I used to do OOP with C. It was a common pattern, back then. We’d pass around structs, and have a small library of functions that accessed/modified the data in these structs. If you wanted, you could add function pointers to the structs. You could add “polymorphism,” by overwriting these pointers, but it was messy. That said, inheritance can be very useful, in some cases, like improving DRY. I don’t…

Reminds me of cube the engine of sauberbraten2 - who uses a C/C++ hybrid with complex inheritance to inherit methods - like everything is a starts as an object. And so on and so forth.. turning inheritance into basically a mapped out set theory with the final class being the outermost part of a set holding the abilities of all inner sets. https://github.com/embeddedc/sauerbraten/tree/master/src

Its not very intuitive used that way.

Re: Fifty Shades of OOP

#67

Post by cjfd »

Rochus wrote: post #12

> The industry and the academy have used the term “object-oriented” to mean so many different things. I think we can safely stick to how IEEE defines OOP: the combination of three main features: 1) encapsulation of data and code 2) inheritance and late binding 3) dynamic object generation (from https://ethw.org/Milestones:Object-Oriented_Programming,_196... ). The article assumes that C++, Java, and Smalltalk impleme…

(1) and (2) sound reasonable enough. What do they mean by "dynamic object generation"?

Re: Fifty Shades of OOP

#68

Post by javcasas »

elric wrote: post #64
javcasas wrote: post #57

Earlier quoted context omitted.

And now you have invented a helper class when all you needed is a namespace. And you already had namespaces.

It doesn't have to be a class. It can be an interface. And regardless of what it is, it has to go somewhere. Whether it's in assorted_functions.c or Permissions.java makes little difference. I mean it makes sense to group "like" things together. Whether that's in a module, a class, an interface, or a namespace. Having a huge number of things globally is just confusing pollution.

> it has to go somewhere

Yes, but going as a static method into a class that goes into a module is overkill vs just putting it in the module.

> Having a huge number of things globally is just confusing pollution.

I don't know what language you use, but modern programming languages allow specifying what to import when importing a module. You don't have to import everything from every module.

Re: Fifty Shades of OOP

#69

Post by mrkeen »

vjvjvjvjghv wrote: post #10
ChrisMarshallNY wrote: post #6

I always considered an "object" to be data with identity and state. All the other stuff, like polymorphism, encapsulation, etc., I consider "addons."

I think the biggest mistake was to teach inheritance as a main feature of OOP. I have done some stuff with inheritance but it was very specialized and it would have been fine without inheritance.

But OOP needs something to distinguish it from the rest, otherwise it's just P.

Do people honestly think other languages don't do whatever definition OOP has today? Encapsulation & polymorphism? Message-passing & late-binding?

Inheritance is the one thing that the other languages took a look at and said 'nope' to.

(Also, the OOP texts say to prefer composition anyway)

Re: Fifty Shades of OOP

#70

Post by mrkeen »

discreteevent wrote: post #42

"The notion of an interface is what truly characterizes objects - not classes, not inheritance, not mutable state. Read William Cook's classic essay for a deep discussion on this." - Gilad Bracha https://gbracha.blogspot.com/2022/06/the-prospect-of-executi... http://www.cs.utexas.edu/~wcook/Drafts/2009/essay.pdf

Let's make the interface so special that it gets its own file type. Let's say '.h' for "header".
Post reply on HN