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

91–100 of 406 posts

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

#91

Post by dep_b »

So one of the problems with that function is that it's global. The advantage of having a single class that either has a hidden constructor and only a static function or needs to be initialized but only offers the stateless function is that you know what concept the function is related to.

Sometimes I have an entirely stateless class that has a cluster of 10 functions, both private and public just to have that particular functionality grouped somewhere.

So class-as-a-namespace if you wish.

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

#92

Post by brnt »

raverbashing wrote: post #59
twic wrote: post #42

Earlier quoted context omitted.

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

Using init/a constructor implies state, does it not?

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

#93

Post by still_grokking »

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

Earlier quoted context omitted.

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.

So you would not use type-classes in Haskell as they rely on implicitly passed parameters to functions?

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

#94

Post by DarkWiiPlayer »

kqr wrote: post #87
cataphract wrote: post #51

Earlier quoted context omitted.

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…

I'd just like to add that you can still have the `A.B(C)` syntax, if you just define it as syntactic sugar for `(class of A).B(A, C)`

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

#95

Post by cessor »

Reducing OOP to implementation detail features will yield poor results. The flexibility stems from an improved means of analysis in that types and entities can be identified more easily. By using classes and objects you're retaining flexibility because they can be interchanged; It's easy to create an object that pretends to be a function; it's harder to make a function retain state later.

The example is nice; it removes a lot of code but also removes the deferred execution aspect of the solution. Calling `countDominoTilings` will make it run in that instance; encapsulating the whole thing makes it able to pass it around and execute the potentially expensive `.count` method later. If applied properly, this can give you quite a lot of flexibility; for some memory and performance tradeoff; but that's the cost of abstraction.

Instead of looking for how FP and OOP are dissimilar, why not start looking for similarities instead? Objects are just higher order functions. Calling ctors is just partial function application.

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

#96

Post by smcl »

I'm always curious when someone recommends reading The Elements of Programming Style. I had seen so many recommendations that one day I decided to dive into it and read through it all myself. The book is a fine read and an interesting snapshot of what coding in 1974 was like. Seeing Kernighan and Plauger analysing and understanding coding issues and formulating early coding best practices is really interesting. However its value as a reference for modern day programmers is heavily overstated - you'll spend most of your time staring at big listings of early Fortran and PL/I code for one thing.

So read it, enjoy it, smile when you see guidance that's still applicable today ... but do not expect to achieve any sort of enlightenment. And be wary if anyone who tells you otherwise.

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

#97

Post by raverbashing »

brnt wrote: post #92
raverbashing wrote: post #59

Earlier quoted context omitted.

If there is state then it makes sense for it to be a class But the parent comment applies

Using init/a constructor implies state, does it not?

    def __init__(self):
        pass
Not necessarily. Or the constructor is just setting some values that are later used by the calculation but are not modified and used later

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

#98

Post by kqr »

goto11 wrote: post #29
jay_kyburz wrote: post #4

I'm fairly new to Unity programming in C# and I was surprised a few months ago that everything in C# must be in a class. As far as I can tell there is no such thing as just a function. Now I have I have a class with some static functions in it.

C# is slowly moving away from "everything is a class". Static classes with static imports is basically a module or namespace. C# also allows stand-alone functions inside methods. But you still have to declare a static class to hold "top-level" functions, which is somewhat ugly. Given the current development of C# I expect we see stand-alone functions in the future.

C# 9 will allow stand-alone functions in the top level program. They do however count as local functions to the top level programs, and will not be accessible from anywhere outside of that context.

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

#99

Post by ClikeX »

cgrealy wrote: post #79
hamandcheese wrote: post #68

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

Just put the function in a namespace?

In Ruby, that basically comes down to creating a static class.

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

#100

Post by noobermin »

fauigerzigerk wrote: post #65
amw-zero wrote: post #54

Earlier quoted context omitted.

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.

The canonical answer is encapsulation. But in my view it's rarely a good idea to couple state related to an algorithm's invocation (e.g a cache) with the data structure itself.

It's almost as if a hard and fast rule doesn't work, ie., the point of the article.
Post reply on HN