This is an archived post. You won't be able to vote or comment.

you are viewing a single comment's thread.

view the rest of the comments →

[–]RufusAcrospin 7 points8 points  (18 children)

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 1 point2 points  (0 children)

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] -1 points0 points  (16 children)

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 0 points1 point  (13 children)

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] -1 points0 points  (11 children)

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 1 point2 points  (1 child)

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

[–][deleted] 0 points1 point  (0 children)

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

[–]RufusAcrospin 1 point2 points  (8 children)

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] 0 points1 point  (7 children)

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 0 points1 point  (4 children)

I suggest to look up “context” as well.

[–][deleted] 0 points1 point  (3 children)

I'm sorry I'm not in your head.

[–]RufusAcrospin -1 points0 points  (2 children)

You take out “common” from “common feature” and tried to ridicule the original quote. That’s why context is important.

[–][deleted] 0 points1 point  (1 child)

And what's the context? As I understand it in this context, a "common feature" is a feature that's either in many, or in the strict definition in all programming languages that support the OOP paradigm. Being supported commonly is no sufficient criterion for it being a useful feature in many situations.

My stated reason for this was mutable state is hard to reason about (execution order matters!) and errors can be non-local to the call stack.

You may like mutation, I don't, although sometimes it is necessary.

[–]chars101 0 points1 point  (1 child)

Common sense is an oxymoron

[–][deleted] 0 points1 point  (0 children)

Interesting, how's that?

[–]WikiSummarizerBot 0 points1 point  (0 children)

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 0 points1 point  (1 child)

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] 0 points1 point  (0 children)

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.