Object oriented programming in Python be like:

nah, I'm never complaining about self in Python after having tried the this and that nonsense in JS.

oh, you're using a named function instead of an arrow fn? Guess what, this is not what it used to be anymore.

Wait there's a "that"???
- Only if you define it.
  const that = this
- it's common practice as a workaround to save this when changing contexts, since this may change under you, in callbacks and such
Oh, you assigned a method to a variable before calling it? Congratulations, this is now undefined.
- Yes. There's no telling what this is. this could be anything. We tried to keep track of this, but no one knows when this will change.
Yeah totally agree.
As a non-programmer who's occasionally dabbled with wxPython, I've entangled myself with self.parent.parent and their childs/siblings more than once. At that stage I know my project is done.

Sorry, I'm too Rust-pilled for this OOP nonsense

rs

    

pub fn new() -> Self {
    Self::self().self.unwrap()
}

Reminds me of java
I have Toolkit toolkit = Toolkit.getDefaultToolkit(); seared into my brain. Then there were the bean factories…
- At least with Rust, there is a specific, defensible goal for why it does that.
  Java is just over designed. All of java.io reads like somebody's Object Orientated Programming 101 final project, and they'd get a B- for it. Lots of things where you can see how they're abstracting things, but there's no thought at all in bringing it together in a tidy way.
- Now my brain wants to relate Java somehow to beancounters.
Even regular Rust code is more "exciting" than Python in this regard, since you have a choice between self, &self, and &mut self. And occasionally mut self, &'a self, and even self: Box<Self>. All of which offer different semantics depending on what exactly you're trying to do.
- I'll add that 100% of the above is understood by the compiler. Unlike Python or JavaScript where you don't know how bad you have it until the program is already running.
Having a field called r#self is malicious madness

Explicit vs implicit. Ive always liked it being explicit like that. It's better than magic keywords in say ruby.

Personally the "spaces are code" gets on my nerves for the same reason. It's implicit to the language so you just have to remember.

Break convention

` class foo: def init(cunt, bar): cunt.bar=True

`

Kinda' looks like how a psychotic break feels:-?

- What 2003 forum thread did this comment crawl out of?
- C/C++ are just scripting languages that have to become OS+arch -specific byte-code before execution.
- You're right in that OOP feels very shoehorned in with Python. But not every project has a Linus Torvalds to publicly humiliate horrible ideas and implementations.
- oop hasn't been "hot" for 20 years.
- that’s because anyone who develops oop in Python is mentally ill.
  Hard disagree there. I would argue that most "multi-paradigm" languages converge on the same features, given enough time to iterate. It's not necessarily about hot-sauce. I honestly think its about utility and meeting your userbase where their heads are.
Write a new method, make sure to reference self first. Write a new method, make sure to reference self first. Call the method, make sure to reference self first.
Yeah, I can see it.
- You don't reference self when calling a method, what on earth are you talking about? You start with the instance when calling the method, like most/all other OOP languages.
  Also there are benefits with the explicit self/this to access instance properties. In C++ you need to make sure all class properties/members have a naming scheme that does not conflict with potential parameter names or other names of other variables.