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

Post by munchbunny » Thu, May 28, 2020, 4:06 PM UTC

amw-zero wrote: post #214

JoeAltmaier wrote: post #198

Earlier quoted context omitted.

Sure, you can build your own object and pass the 'this' pointer around manually. You could use C for everything, and tediously do everything again that objects do for free. But why? There's a lot of object-hating going around. Its silly. Use objects to encapsulate functionality, they are good at that and everybody understands what it means.

You don’t agree with an idea so it’s silly? 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 visibility, etc. You can encapsulate functionality without objects. There is nothing that you can do with an object that you can’t do with a closure, and the closure version wil…

Post by crimsonalucard1 » Thu, May 28, 2020, 4:10 PM UTC

JoeAltmaier wrote: post #198

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.

Sure, you can build your own object and pass the 'this' pointer around manually. You could use C for everything, and tediously do everything again that objects do for free. But why? There's a lot of object-hating going around. Its silly. Use objects to encapsulate functionality, they are good at that and everybody understands what it means.

Post by kyralis » Thu, May 28, 2020, 4:12 PM UTC

totony wrote: post #220

nitrogen wrote: post #218

Earlier quoted context omitted.

I don't find all that much of a difference between notations like set.map{...} and map(set){...}, so at that point I suppose it really is just aesthetic preference.

Classes usually have a more complex state than the state passed to utility functions, which is a reason I'd be incline to use e.g. a struct as a state vs a C++ class. Makes it harder to write bad code.

Post by eternauta3k » Thu, May 28, 2020, 4:14 PM UTC

Const-me wrote: post #155

fnord123 wrote: post #113

Earlier quoted context omitted.

Let's use C and C++ as an example. What does the code look like? myobj.cool_func(1,2,3); // C++ cool_func(myobj, 1, 2, 3); // C Is this better? If you use a vanilla C++ style class then the class definition is in the header. All changes to the class require a recompilation and break the ABI of the class. This means you basically cannot release patch versions of your library because consumers cannot link against it if…

> Is this better? Very few professional developers code in vim or notepad. Vast majority of us are using IDEs. IDE knows types of things, type `myobj.` and you'll get a suggestion list with methods of that class callable from the current context. > There is then a pattern to do this in C++ called pimpl There's another useful pattern in C++: struct iObj { virtual ~iObj() { } virtual void cool_func( int a, int b, int c…

Post by crimsonalucard1 » Thu, May 28, 2020, 4:18 PM UTC

optimiz3 wrote: post #238

amw-zero wrote: post #214

Earlier quoted context omitted.

You don’t agree with an idea so it’s silly? 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 visibility, etc. You can encapsulate functionality without objects. There is nothing that you can do with an object that you can’t do with a closure, and the closure version wil…

> Passing around state via variables is no more tedious But it is - the programming language is now repeatedly quizzing you on something you've already told it.

    method(state){
        return doSomething(state)
    }

   class A:
       otherThingThatMutatesState1()
       otherThingThatMutatesState2()
       otherThingThatMutatesState3()

       method(){
          this.state += 1 // or some other mutation
       }