The use of `class` for things that should be simple free functions • Hacker News Board

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

#401

Post by vlovich123 » Sat, May 30, 2020, 6:20 AM UTC

steerablesafe wrote: post #148

vlovich123 wrote: post #40

Earlier quoted context omitted.

Mutable in C++11 land holds a weird space because the threading model says that const member methods are thread safe, which mutable member variables are not.

Yes, access to mutable members should be synchronized in const methods.

> A C++ standard library function shall not directly or indirectly modify objects (1.10) accessible by threads other than the current thread unless the objects are accessed directly or indirectly via the function’s non-const arguments, including this

Consider the case where I invoke `std::find_if`. It takes const iterators to a std::vector. I'm now indirectly modifying objects through standard library functions that are modifying objects by multiple threads through const arguments. Using a mutex doesn't change the fact that my usage of the STL is now in undefined behavior land.

I think the only safe thing to do is to have a mutable mutex (there may be other parts of the legalese) but outside of that you may run into serious trouble at some point compilers become intelligent enough to enforce that undefined behavior. Realistically I doubt any compiler would ever enforce that legalese because of how const & mutable both are interpreted to mean "this variable is thread-safe" by everyone involved so a mutable variable that is synchronized in some way will always work fine.

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

#402

Post by tempodox » Sat, May 30, 2020, 12:20 PM UTC

quietbritishjim wrote: post #211

tempodox wrote: post #204

Earlier quoted context omitted.

What you call “for free”, I call implicit. Passing it as function arguments makes it explicit. You don't need to “hate” “objects” to prefer the explicit over the implicit.

I think you could apply your argument to any use of objects, unless there are virtual methods involved. So you probably would have to be pretty generally against the use of objects to agree.

Classes for use with stack-allocated instances in C++ are also very handy. Makes it easy to control the extent (i.e. lifetime) of the side-effects they produce.

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

#403

Post by cessor » Sun, May 31, 2020, 11:44 AM UTC

moonchild wrote: post #397

cessor wrote: post #371

Earlier quoted context omitted.

Members in Python are never private. Variables that are supposed to be used internally only are marked with and underscore, but that just conveys intent and isn't enforced by the interpreter/runtime. But you can emulate private data like this: >>> def a(u, v): ... def b(): ... return u + v ... return b ... >>> b = a(1,2) >>> b() 3 Like this, there is no way to access u & v from b.

Looks like classes can't be closures, though: >>> def f(): ... x = 5 ... class Blub: ... def incx(self): ... x += 1 ... def getx(self): ... return x ... return Blub() ... >>> j = f() >>> j.incx() Traceback (most recent call last): File " ", line 1, in File " ", line 5, in incx UnboundLocalError: local variable 'x' referenced before assignment

When using it like this, the interpreter opens a new namespace where the variables are bound. The x is declared in the outer scope, so it can't find it. However, you can ask python to keep searching vor the name `x` in the closest outer scope, that is what the `nonlocal` statement is for:

    def f():
        x = 5
        class Blub:
            def incx(self):
                nonlocal x
                x += 1

            def getx(self):
                return x

        return Blub()

    j = f()
    j.incx()
    print(j.getx())

This will print 6, as expected.

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

#404

Post by chrisrichard » Sun, May 31, 2020, 2:22 PM UTC

skratlo wrote: post #292

munchbunny wrote: post #262

Earlier quoted context omitted.

the closure version will be 1/10th the size and have 1/10th the semantic programming language elements This seems pretty central to your point, but a factor of 10 is also a very strong claim. I'd like to see sources. Passing around state via variables is no more tedious than the extra syntax for class definitions, constructors, member variable access, extra semantics related to objects, extra keywords related to visi…

You're saying what? Doing objects that act just like closures? :)

OO - data with functions

Closures - functions with data

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

#405

Post by kortilla » Sun, May 31, 2020, 7:00 PM UTC

nightski wrote: post #393

kortilla wrote: post #277

Earlier quoted context omitted.

If you’re asserting non-public internals of a class, your testing is wrong in the first place. Assert outcomes, not the process.

That's the whole point. You can't test outcomes if they are dependent on internal hidden state as that affects the outcome. Whether you make it private or not hidden state leaks into the output since the output is dependent on it.

It sounds like you’re confusing side effect free code with OOP. You can use OOP while having side effect free stuff that never requires you to assert internals.

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

#406

Post by ric2b » Mon, Jun 01, 2020, 10:44 PM UTC

tarkin2 wrote: post #74

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

And if you have many methods, but only one 'public' method, use a closure.

I often run into that situation because I'm trying to make the main method a lot simpler by breaking it up into smaller methods with good names. Why should I avoid it?