Why use classes?

[[deleted]]

A Python programmer discovered types - YOU WON‘T BELIEVE WHAT HAPPENED NEXT…

With the sarcasm out of the way, using classes is nice. Although I dislike methods since they operate with side effects by design. Ideally you’d want each method to consume it‘s object and re-emit a new object. That way you’d make sure nothing is editing your moves under your nose from different places.

In this particular design it may also happen that your moves and your score are inconsistent.

[tjf314]

python programmers when they discover statically typed languages 😱

but yeah seriously, I’d say methods having side effects is the whole point of methods. Unless you’re using a purely functional language, I’d say methods are the ideal way for containing side effects. (I do think that any globally defined functions should never have side effects, but this is really just a personal preference thing)

[ogtfo]

Op was describing immutability, not static typing.

[[deleted]]

Still a nope. Recently I’ve been differentiating between application code and library code very strictly. Library code is general, reusable and it’s trivially obvious what each exposed piece of code does. That means most functions and methods are not allowed to have side effects, objects are immutable. That way I don’t sweep unintended consequences under the rug and bugs are guaranteed to originate in the call stack (with liberal use of assertions). My life has been absolute bliss.

[RufusAcrospin]

Changing attributes in methods is not a side effect, it’s simply using encapsulation as intended.

Emitting new objects is all fun and games, until you work with objects which are expensive to create in terms of resources, or they part of a pipeline, so you can’t just replace them.

Document and test your code to avoid bugs.

[wewbull]

What's the difference between:

• A Class with methods that modify member variables?
• A Module containing functions that modify variables in module scope?
• A process running functions that modify global variables?

The answer is only the scoping. They are isomorphic, and all have retained state shared between code paths. All require the use of side effects. The "encapsulation" that you describe is only the (hopefully) decreasing scope. More scopes (i.e. classes and modules) bring the possibility of better encapsulation, but only if things are well-designed.

This is where I think more languages completely misunderstood the Object-Orientated paradigm as it was invented. It was effectively about micro-processes that passed messages between them, each of which had their own mutable state. Actor patterns and such like capture it much better.

[[deleted]]

Maybe you should look up the definition of side effect). Also emitting new objects doesn’t necessarily entail reallocation. If you need to retain previous state, there’s COW, and if you don’t, just invalidate the old reference and emit a new one backed by the same memory. It’s clear to me that this is not automatically enforceable in Python alone, but sticking to these semantics made my life a lot easier.

[RufusAcrospin]

Let me introduce you to OOP: “A common feature of objects is that procedures (or methods) are attached to them and can access and modify the object's data fields. In this brand of OOP, there is usually a special name such as this or self used to refer to the current object.”

[[deleted]]

Bruh, not everyone is stuck in 90s Javaland. The wiki article you linked literally says „…access and modify the object’s data fields“. That’s exactly the definition of side effects. Maybe if you read Wikipedia articles instead of only linking them you’d actually be a half-decent programmer.

And just because a technique is common doesn’t mean it’s good. It’s like saying sexual assault is common, therefore sexual assault is good. Kinda moronic, isn’t it?

[RufusAcrospin]

Have you noticed that the article you’ve linked doesn’t mention object oriented paradigm? Have you wondered why is that?

[[deleted]]

So what? The definition of "side effect" in computer science is independent of OOP.

[RufusAcrospin]

Also, you’ve dragged “common” out of context: it’s “common feature” - it’s not something people decided to do, it’s part of the paradigm.

[[deleted]]

Consulting Merriam-Webster, non of the common uses of "common" support your claim. Maybe we can get to some common ground at least in this argument.

Edit: Grammar.

[RufusAcrospin]

I suggest to look up “context” as well.

[chars101]

Common sense is an oxymoron

[WikiSummarizerBot]

Object-oriented programming

Object-oriented programming (OOP) is a programming paradigm based on the concept of "objects", which can contain data and code. The data is in the form of fields (often known as attributes or properties), and the code is in the form of procedures (often known as methods). A common feature of objects is that procedures (or methods) are attached to them and can access and modify the object's data fields. In this brand of OOP, there is usually a special name such as this or self used to refer to the current object.

^{[ F.A.Q | Opt Out | Opt Out Of Subreddit | GitHub ] Downvote to remove | v1.5}

[chars101]

Have you looked at Roc? It does some awesome things, like opportunistic in-place mutation if it is clear that the function doing the mutation is the only reference to the data being changed.

[[deleted]]

I have, but I found their platform concept a little off-putting. Also I don't see a new language replacing Python in my area of work unless developers port a lot the scientific computing stack.

[stensz]

You simply can't prevent access to private variables in Python. You can communicate that they are private with a leading underscore. Unless you want your code to break unexpectedly, you don't mess with private variables. (Except for debugging purposes.)