Hacker News Reader

Comment by RyanZAG | Hacker News Reader

If you think of classes as namespaces and not objects (which is what they are half the time), it becomes a bit saner. Pragmatism makes the world work.

You can still write functional code in OO. Heck if it makes you feel better, you can just make a macro to rename 'namespace' to 'class' and then you can write code like

  namespace Utils {
   function thingy() {...}
  }

Namespaces are generally an improvement over globally defined functions as it lets you mix and match libraries without having to worry that you included the right header files, etc. Again, pragmatism.

View on HN

Agreed. I think the problem with OOP (at least in most common implementations) is that objects (and/or classes) just do too much. They serve as complex data types, records, code modules, contracts, callback containers, etc. It's hard to grasp disparate concepts when you keep calling them the same name. Even harder to construct and explain more advanced stuff layered on top, such as various design patterns that actually make those objects useful.

You can make good arguments in either direction - either having a single generic type (a class) that fits all of these concepts, or having specific types for each of those concepts.

Having just a generic type gives the language some useful simplicity as the single 'class' container can fulfill all of those needs yet not need the user to remember all the caveats of each specific type as the 'class' concept is generic enough to fit to almost anything.

Having specific types is very good for teaching the different concepts at a higher level as well as documenting what is intended for future readers of the code (as long as they also understand all of the concepts involved). Convention over configuration, really.

I personally prefer the more generic types as they don't try to lock you in to the authors specific biases and requirements - that's what frameworks are for.

Classes do too much if you dont have Roles.

When you have Roles, you can build a class with Roles. like lego. Then you can have specific roles and build a class with Roles.

If your OO doesnt support Classes, Roles, Types and method modifieds and functional programming, its outdated.

Seems like your outdated OO needs a metaclass system, up-to-date like Moose from perl.

Just about any OO system can do this using interfaces, abstract base classes, mixins, traits etc. Yes it is a good way to approach design rather than building unique behavior from scratch over and over. But you don't need to go anywhere near PERL to accomplish this.

Agree. I find it quite interesting how the concept of classes resp. objects has been adapted and moved away from what they really were let's say in Smalltalk (message processing entities) ... and I think this "progress" was not for better regarding the clarity of the concept.

I think this progress has to do with "type systems" and additionally with the very powerful tools c++ f.e. added to the tool box. The more powerful the toolbox the harder it is to truly grasp it, it seams which steepens the learning curve considerably unless only the very rudimentary "features" of oop are used, as it happens mostly in commercial 9-5 software development.

Have you programmed in Smalltalk? Classes tend to do a lot more (well everything that can be done) compared to C++. Smalltalk has a clean design for the core parts so these hang together pretty well. Nonetheless, inheritance hierarchies are deep and there are many fat classes. So small size in itself is usually not a virtue, clarity in role is on the other hand.

I think you're conflating languages that strongly support OO with OO itself. OO is a paradigm, a way of organizing your program. Using classes (meaning, as a language primitive) as namespaces and not as, well, classes is specifically avoiding OO programming. That's fine and, like you said, perfectly pragmatic, but it's not writing "functional code in OO". It's just repurposing language primitives that were designed for OO .

I agree with your specific response here, but I think it's worth pointing out that it is in fact possible to mix OO and FP (ruby is particularly suited for it). You can design systems around classes which are treated as value objects, immutable once initialized, and thus maintain the core tenets of OO and FP in a single program.

I guess the definitions of FP and OO are fuzzy enough that someone will probably come and tell me why this isn't a true Functional architecture, but so far I haven't seen anything close though to a consensus on what the strict requirements of FP really are such that it would preclude any form of binding data and methods. Specific languages are one thing, but when talking about programming paradigms in general I see them as forming a hugely overlapping Venn diagram.

Yes, I fully agree with that.

Most modern languages (aka post-C) already have namespaces, why would anyone need to use classes as namespaces? You can just have functions that operate on set of data, keep it tight and clean, no need for classes if you don't need oop.

Imo forcing classes in a non-oop paradigm is just clumsy and, well, unnecessary. When you have a hammer... etc etc

javascript

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

But what if namespaces were values that you could pass around? What if a namespace could be abstract, much like an interface, defining abstract functions and even abstract types? What if you could override the "import" statements a particular module uses?

> no need for classes if you don't need oop

It really depends on what you mean when you say "classes". When I think of classes, I think of subtyping, as in, if type B is a subtype of type A (B <: A), then it means a value of type B can be used in any expression that demands a value of type A (i.e. the substitution rule).

SML has a pretty cool module system that allows for what I say above. But SML modules are special. The cool thing about OOP, when implemented right, is that you don't need special language semantics for special things, as every value can be some sort of object and every type or module can be some sort of class. You know, in a turtles all the way down kind of thing.

See this presentation about the Cake pattern, in Scala: https://www.youtube.com/watch?v=yLbdw06tKPQ

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.

> 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.

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.

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.

Agreed, and in my primary language, C#, these days I would rather just write static classes with static methods and pass in other static methods instead of messing around with interfaces all the time. I write ASP.NET MVC so I don't use state for the most part.

Ok, so I don't do that with controllers for obvious reasons, but my business logic and utilities I try to.

"I write ASP.NET MVC so I don't use state for the most part."

Nor unit tests I assume

Care to explain?

The use of statics makes mocking and testing very difficult.

A few thoughts on the subject: http://misko.hevery.com/2008/12/15/static-methods-are-death-...

If you use static classes for business logic, you typically end up with a tightly coupled system in which managing class dependencies is a pain.

I think that "messing around with interfaces all the time" is worth the fuss in the long run.

Reply on news.ycombinator.com