Live data from Hacker News

The use of `class` for things that should be simple free functions

quuxplusone.github.io

81–90 of 406 posts

Re: The use of `class` for things that should be simple free functions

#81
post #2

For anyone who wants to post their opinions on whether OOP is good or bad, may I suggest briefly explaining what you consider to be "object-oriented programming"? I've seen in a lot of threads like these, people often end up talking past each other, because one person's idea of what an "object" turned out to be different from someone else's.

I would really love to hear it too. I made some OOP on various programming languages (mainly PHP/Ruby) and where sometimes this is obvious that using OOP is the solution (interfaces, abstract classes etc), sometimes I feel it is completely overkill and I don't even know why I'm using it. For example recently, as an exercise, I made a little scraper in Python to extract movies data from a website [1]. This could have…

Traditionally, I don't really like classes, as I started with a mostly functional language (R).

However, when writing Python (for a poker simulator), I came to the conclusion that objects can actually be really useful for the following reasons: 1) managing state: this is the big one, if you need data with your functions, a class is an obvious way of doing it.

2) documentation: a class with methods is a higher-level structure than a bunch of functions and you are more likely not to forget the existence of a method on a class relative to a function somewhere in your code base (this second idea shamelessly stolen from Martin Fowler).

Re: The use of `class` for things that should be simple free functions

#82
general rule of thumb here is: to use classes if there are some invariants that can be checked/maintained. or, in other words, invariants exist to justify the existence of classes. ofcourse, the constructor establishes the invariants, and everyone else maintains it.

if you have to do things like 'get_name(...)' and 'set_name(...)' then it is kind of silly (imho). just stick to more canonical means.

Re: The use of `class` for things that should be simple free functions

#83

Counter-point: while in many situations this isn't the right approach, it's worth recognizing when this is the right approach, because they can look awfully similar. An example of this is graph searching, e.g. BFS or Dijkstra's algorithm. The typical implementation is a function. But if you make Dijkstra a class, with (say) a function to iterate through nodes, it lets you do several things that would be difficult wit…

None of these situations require an object to do. You can always have a function that takes in an extra ‘state’ argument. You can then do everything you said by passing in the corresponding state values.

If you're at the point where you'd rather pass a state argument around rather than use an object you've thrown out OO categorically and there's no point to even discuss anything. The article in question talks about when it makes sense to use functions within the OO paradigm instead of classes.

Generally using classes when modelling persistent state is not an anti-pattern, because that's what classes are for.

Re: The use of `class` for things that should be simple free functions

#85

Earlier quoted context omitted.

Classes in OOP are type dependent namespaces. That's the entire reason why classes even exist. You can now reuse function and member names inside classes instead of having to globally qualify them to prevent name collisions. In C you would do something like class_name_function_name(var, par1, par2). The OOP counterpart would look like this in Java: ClassName var = new ClassName(); var.functionName(par1, par2). Now yo…

A static class in C# can't have any instance data, instance methods, and can't be instantiated. It's literally a namespace in everything but name.

But it does have class scoping rules. You can have public and private static members.

Re: The use of `class` for things that should be simple free functions

#87

Earlier quoted context omitted.

None of these situations require an object to do. You can always have a function that takes in an extra ‘state’ argument. You can then do everything you said by passing in the corresponding state values.

But if you're passing a state object around, you might as well use a class, no? Admittedly simplifying a bit, an instance method is a function that implicitly takes "this" as the first argument.

There's one big difference in terms of convenience in many common implementations of classes and methods. There are essentially three different pieces involved:

In OO notation, we have A.B(C)

In almost all languages, you can store C in a variable and supply it "later":

    z = C
    A.B(z)
You can also store A in a variable and supply it "later":

    x = A
    x.B(C)
However, it is much more rare to be able to store B in a variable and supply it "later". Often, you must store A.B:

    xy = A.B
    xy(C)
This means that at the time you select which method to call, you must also have at your disposal the instance on which you want to call it!

With functions, things get easier. If you have B(A, C), you can generally just store B in a variable on its own:

    y = B
    y(A, C)
Some OO languages allow you to store plain methods that aren't yet bound to a particular instance (JavaScript, modern Java) but far from all do, without resorting to inconveniences like

    y = lambda o: o.B
Please note that what this workaround accomplishes is effectively to turn the method into a function!

I suspect the main argument here is that it just doesn't make sense notationally to treat the first argument to a function specially. It only introduces wierd edge cases that have to be worked around. Plain old function notation has stood the test of time for good reason: it's flexible and handles most of the common cases we want.

Re: The use of `class` for things that should be simple free functions

#88
post #2

For anyone who wants to post their opinions on whether OOP is good or bad, may I suggest briefly explaining what you consider to be "object-oriented programming"? I've seen in a lot of threads like these, people often end up talking past each other, because one person's idea of what an "object" turned out to be different from someone else's.

I would really love to hear it too. I made some OOP on various programming languages (mainly PHP/Ruby) and where sometimes this is obvious that using OOP is the solution (interfaces, abstract classes etc), sometimes I feel it is completely overkill and I don't even know why I'm using it. For example recently, as an exercise, I made a little scraper in Python to extract movies data from a website [1]. This could have…

For PHP, one reason why I decide to use a class because there is no autoloading support for functions.

This allows me to logically group functions _and_ throw in autoloading support.

Re: The use of `class` for things that should be simple free functions

#89

Is there any real harm though? Free functions pollute the global namespace, which is something I tend to avoid (at least in Ruby where everything shares the same namespace).

What's the difference between polluting the global namespace with a class name, or with a function name? I get it, I also experience some reticience when adding free/bare functions in Swift. But maybe it's because of 15 years of OOP programming.

Maybe not so much of a problem in C++ but look at JavaScript. With the millions of dependencies / libraries you import, if they all used free standing functions you would inevitably end up with collisions.

Re: The use of `class` for things that should be simple free functions

#90
“the count() member function sounds like it should be non-modifying, but in fact it needs to update member data and thus cannot be const”

That isn’t correct. Just declare count as mutable. See https://en.cppreference.com/w/cpp/language/cv. Memoization is a valid use case for that feature.

Post reply on HN