Hacker News Reader

Comment by wtetzner | Hacker News Reader

No, it's just some sugar over plain old functions.

It's basically how Python methods work, and while I'm sure you could no-true-scotsman Python classes/OO, I have yet to see it.

Right, but there's more to classes in Python than just methods (inheritance etc.).

Inheritance is not essential to OO; it is merely a method of sharing code.

Sure, and functions are just sugar over goto's.

Are you suggesting that the difference between a.foo(b) and foo(a, b) is analogous to the difference between goto and functions? Functions give structure and restrictions to goto. Method syntax is just a different way to write the exact same thing.

I'm suggesting all of programming is syntactic sugar. Calling something syntactic sugar is not a valid critique.

> I'm suggesting all of programming is syntactic sugar. I wasn't critiquing anything, just suggesting that moving the first argument of a function call to come before a . isn't enough to consider something OO.

There's typically more to OO than just method syntax. Dynamic dispatch, subtyping, etc. And saying something is OO without encapsulation isn't really saying anything, given that encapsulation is arguably the most important part of OO.

I'd argue that, it's not remotely the most important part nor is sub-typing. Encapsulation encourages better OO, but you can take a well encapsulated OO program, and remove all encapsulation by making all the data public, and that program is still a well structured OO program. OO is about the way objects talk to each other to accomplish work, the message, the API between objects; it's not about the many little things like encapsulation that encourage better messaging. There are dozens of practices that encourage better OO, but you can write good OO without them if you know what good OO is and don't need those training wheels.

If you don't have encapsulation, then you're not just using messages to talk between objects. If you are, then you have encapsulation.

Well, now we have to get semantic; if by encapsulation you mean you keeping your data private and only exposing behavior publicly, then you're wrong. If by encapsulation you mean all behavior that uses an objects data is in the object and no outside code relies on that objects data even if it is public, then you're agreeing with me.

You clearly didn't play out my thought experiment above or you wouldn't be making the statement you just made.

I agree that in your thought experiment, the program remains OO, but the language is not. You can write OO programs in many languages, but I would argue that you don't have an OO language unless it has special support for OO programming.

I wasn't arguing it was an OO language, merely that it was OO code. OO used to be done in C in exactly the same basic way, passing the struct that is the object as the first arg to all the member functions; Python does this explicitly as well.

OK, I was talking about whether or not the language was OO. So I guess we're in agreement then :)

Reply on news.ycombinator.com