Hacker News Reader

Comment by Jormundir | Hacker News Reader

You're basically asking what if a namespace were a class.

> Namespaces in Java, C++, C#, or whatever else is in this family, are simply too dumb. Their sole purpose is to avoid name clashes.

That statement is just completely ridiculous. Classes are for inheritance, abstraction and polymorphism. You're saying you think of classes as inheritance and polymorphism without encapsulation, but encapsulation is the key trait for decoupling.

It's been awhile since I worked with SML, but if I recall, the modules you say are cool and special, are cool and special because they give you the three important traits of OOP.

View on HN

but encapsulation is the key trait for decoupling.

Abstraction is the key trait for decoupling, not encapsulation. Encapsulation couples behaviour and state together.

Can you give an example? My thought is you can make a bunch of well abstracted objects, but still have a very tightly coupled system. If one class is free to use the internals of another, it's free to tightly couple itself to another class, regardless of the abstractions involved.

I see where you're coming from though, and I think decoupling is a combination of abstraction and encapsulation, not one or the other exclusively.

If one class is free to use the internals of another, it's free to tightly couple itself to another class, regardless of the abstractions involved.

If one class is free to use the internals of another then it is not a sound abstraction by definition.

I see where you're coming from though, and I think decoupling is a combination of abstraction and encapsulation, not one or the other exclusively.

Your view of abstraction is too limited. Abstraction need not involve classes or objects at all. Abstractions may also be built with modules/namespaces, parametric polymorphism (aka generics) and other forms of ad-hoc polymorphism (such as type classes). All that is required to achieve abstraction is a function or data type which hides its implementation details in a way that allows it to be interchanged freely with other functions or data types that match its interface. Encapsulation is only one way to achieve such hiding.

Well then likewise, your idea of encapsulation is too limited.

> If one class is free to use the internals of another then it is not a sound abstraction by definition.

So abstraction is not sound without encapsulation.

> You're saying you think of classes as inheritance and polymorphism without encapsulation

I don't know whatever gave you that idea, but it's quite the opposite, unless we have completely different definitions for what encapsulation is.

What three important traits? If you're talking of "inheritance, abstraction, and polymorphism" that you've mentioned, then I'd like to observe that inheritance is orthogonal to OOP, abstraction is essentially named definitions as a language feature (see Abelson, Sussman, Sussman, 1996, Chapter 1), and polymorphism, again, is found in many non-OOP languages, such as Haskell, for example.

Reply on news.ycombinator.com