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

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

quuxplusone.github.io

Post reply on HN
Print view View original

51–60 of 406 posts

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

#51

Post by cataphract »

amw-zero wrote: post #48
dataflow wrote: post #18

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.

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.

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

#52

Post by ben-schaaf »

heavenlyblue wrote: post #45
moonchild wrote: post #14

Earlier quoted context omitted.

Python doesn't have private members, so that doesn't help you as much.

Python has private members through double underscore methods

They're only private in a sense that you're not supposed to access them, there's no enforcement by the language in any way beyond renaming them `___`. They're still accessible and they still show up in `dir`, `__dict__`, etc.

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

#54

Post by amw-zero »

cataphract wrote: post #51
amw-zero wrote: post #48

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.

Why? You would never suggest this if OO wasn’t the predominant paradigm. What is the benefit of implicitly passing the parameter? I prefer to see it passed explicitly, so the implicit passing is a downside to me, not a benefit.

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

#56

Post by jcelerier »

amw-zero wrote: post #50
jcelerier wrote: post #12

A lot of time where I just write simple functions, I end up having to wrap them into objects because it is much more convenient when I want to do static polymorphism - sure, that function I'm writing now doesn't need state but then two days after I have to refactor because the next strategy I use does indeed require state. e.g. : template struct MyAlgorithm { F1 f1; F2 f2; void operator()(...) { ... f1(whatever); ...…

This is a limitation of C++, not functions.

yeah... but that's a C++ article, written by someone who contributes to the C++ standard... the context seems unambiguous

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

#57

Post by sebsito »

Depending on the language it could be tricky. For example in Ruby everything literally is an object. There are no standalone functions. Not having a class simply makes it hard to use. I can't autoload methods. I could group them in a module but that's not the point. So while coding in Ruby I'm planning to stay with small classes. I treat class as a smallest testable entity in Ruby.

On the contrary, in Python, a function is a first class citizen which can be selectively imported and easily tested.

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

#58

Post by jordinl »

sebsito wrote: post #57

Depending on the language it could be tricky. For example in Ruby everything literally is an object. There are no standalone functions. Not having a class simply makes it hard to use. I can't autoload methods. I could group them in a module but that's not the point. So while coding in Ruby I'm planning to stay with small classes. I treat class as a smallest testable entity in Ruby. On the contrary, in Python, a funct…

> For example in Ruby everything literally is an object. There are no standalone functions. Not having a class simply makes it hard to use

Nothing prevents you from writing one function in a file, requiring that file and calling that function. Not sure what's so hard about it.

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

#59

Post by raverbashing »

twic wrote: post #42
makapuf wrote: post #3

Also known in python as "if your class has only two methods, one of which is init, it's a function" in the "stop writing classes" https://www.youtube.com/watch?v=o9pEzgHorH0 EDIT: typo, changed link

I have a few little classes that are clients for network services. They have a constructor which sets up an HTTP client or socket or something, and maybe prepares some metadata, and then a method to make a call to the service. I could write these clients as lambdas or nested functions which close over the stuff which init creates. But why? An object makes it much clearer that there is state.

If there is state then it makes sense for it to be a class

But the parent comment applies

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

#60

Post by Tomte »

dang wrote: post #28
skrebbel wrote: post #24

Patterns and antipatterns are important, but naming is even more important. Calling "using a class when a function would suffice" "the OO antipattern" isn't going to help anybody. I wish we wouldn't let today's tendency towards clickbait titles extend into engineering terminology.

I agree - it's baity and misleading, and so should be changed ( https://news.ycombinator.com/newsguidelines.html ). I've replaced it with the article's phrase for what it's really about.

In this case I don't find it terribly misleading.

One thing that occurs to me regularly now is that I click on a submission that's new to me – only to find that I've already seen it under a different title.

I agree with the policy of renaming submissions, but I wish you'd adjust your trigger level slightly towards less changes.

Post reply on HN