▲ 472 ▼ Object oriented programming in Python be like: (media.piefed.ca) submitted 1 year ago by albbi@piefed.ca to c/programmer_humor@programming.dev 48 comments fedilink hide all child comments
[–] Lightfire228@pawb.social 51 points 1 year ago (3 children) Sorry, I'm too Rust-pilled for this OOP nonsense pub fn new() -> Self { Self::self().self.unwrap() } permalink fedilink source hideshow 6 child comments replies: [–] panda_abyss@lemmy.ca 28 points 1 year ago (2 children) Reminds me of java I have Toolkit toolkit = Toolkit.getDefaultToolkit(); seared into my brain. Then there were the bean factories… permalink fedilink source parent hideshow 4 child comments replies: [–] frezik@lemmy.blahaj.zone 16 points 1 year ago (1 child) 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. permalink fedilink source parent hideshow 2 child comments replies: [–] Fiery@lemmy.dbzer0.com 5 points 1 year ago (2 children) Not like C# is all that much better. So much garbage in the fundamentals just because it was done that way at the start and "they can't change it now". The best example is the IList interface. Theoretically this interface exposes both index-based access and collection-like modifications and as such would be perfect in a function if you need those two features on a type. In reality you can't use it as a function parameter because half the official types implementing IList aren't modifiable and throw a runtime error. E.g Arrays permalink fedilink source parent hideshow 4 child comments replies: [–] kogasa@programming.dev 2 points 1 year ago* (1 child) That's a footgun sure but at least you can avoid it once you're aware of the problem. I never write function signatures with mutable interfaces. It's always IEnumerable, IReadOnlyCollection, or IReadOnlyList; otherwise, use a concrete type. The latter is typical for private/protected methods that are called with instance members of a concrete type rather than public interfaces. If you want to mutate an object, you should own it. Public methods are invoked with data not owned by the instance. For example, a lot of extension methods in LINQ have a signature IEnumerable --> IEnumerable, and internally the first thing they do is call .ToList(). The interface makes minimal assumptions about the input data, then puts it into a concrete type you can manipulate efficiently. You can similarly define a method for IReadOnlyList and explicitly make it mutable via .ToList(), rather than use IList and check .IsReadOnly. Both ensure correctness but the former does it at the type level, at design time, instead of relying on runtime checks. C# is old and full of oldness. But it's also an excellent language that can be written beautifully if you know how. And there's lots of great code to learn from in the open-source dotnet core runtime repo and related projects. permalink fedilink source parent hideshow 2 child comments replies: [–] Fiery@lemmy.dbzer0.com 2 points 1 year ago (1 child) Functional programming fixes the problem by simply not making it OO anymore, and while I'm personally a big fan of the paradigm there are situations where an OO approach is preferable (or even only to conform to a project's existing way of doing things). permalink fedilink source parent hideshow 2 child comments replies: [–] kogasa@programming.dev 1 point 1 year ago What I described isn't necessarily functional. This is just a principle for ensuring objects represent clear and well-defined contracts. The idea is that to mutate something, you should own it; that means interfaces / public APIs, which can be called externally, should take immutable arguments. You can still mutate instance members internally because those are owned by the instance. If mutation is really necessary between two objects then it should be coordinated by an object owning them both. permalink fedilink source parent [–] ThirdConsul@lemmy.ml 1 point 1 year ago Oh god, I didn't knew that. That's funny. permalink fedilink source parent [–] MonkderVierte@lemmy.zip 2 points 1 year ago (1 child) Now my brain wants to relate Java somehow to beancounters. permalink fedilink source parent hideshow 2 child comments replies: [–] panda_abyss@lemmy.ca 1 point 1 year ago Well it is owned by Oracle now permalink fedilink source parent [–] shape_warrior_t@programming.dev 18 points 1 year ago (1 child) 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. permalink fedilink source parent hideshow 2 child comments replies: [–] dejected_warp_core@lemmy.world 8 points 1 year ago (1 child) 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. permalink fedilink source parent hideshow 2 child comments replies: [–] Lightfire228@pawb.social 7 points 1 year ago At least python has a decent runtime typing system JS's type system feels like what you'd get by giving a monkey access to unlimited cocaine and a computer permalink fedilink source parent [–] PlexSheep@infosec.pub 12 points 1 year ago Having a field called r#self is malicious madness permalink fedilink source parent
[–] panda_abyss@lemmy.ca 28 points 1 year ago (2 children) Reminds me of java I have Toolkit toolkit = Toolkit.getDefaultToolkit(); seared into my brain. Then there were the bean factories… permalink fedilink source parent hideshow 4 child comments replies: [–] frezik@lemmy.blahaj.zone 16 points 1 year ago (1 child) 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. permalink fedilink source parent hideshow 2 child comments replies: [–] Fiery@lemmy.dbzer0.com 5 points 1 year ago (2 children) Not like C# is all that much better. So much garbage in the fundamentals just because it was done that way at the start and "they can't change it now". The best example is the IList interface. Theoretically this interface exposes both index-based access and collection-like modifications and as such would be perfect in a function if you need those two features on a type. In reality you can't use it as a function parameter because half the official types implementing IList aren't modifiable and throw a runtime error. E.g Arrays permalink fedilink source parent hideshow 4 child comments replies: [–] kogasa@programming.dev 2 points 1 year ago* (1 child) That's a footgun sure but at least you can avoid it once you're aware of the problem. I never write function signatures with mutable interfaces. It's always IEnumerable, IReadOnlyCollection, or IReadOnlyList; otherwise, use a concrete type. The latter is typical for private/protected methods that are called with instance members of a concrete type rather than public interfaces. If you want to mutate an object, you should own it. Public methods are invoked with data not owned by the instance. For example, a lot of extension methods in LINQ have a signature IEnumerable --> IEnumerable, and internally the first thing they do is call .ToList(). The interface makes minimal assumptions about the input data, then puts it into a concrete type you can manipulate efficiently. You can similarly define a method for IReadOnlyList and explicitly make it mutable via .ToList(), rather than use IList and check .IsReadOnly. Both ensure correctness but the former does it at the type level, at design time, instead of relying on runtime checks. C# is old and full of oldness. But it's also an excellent language that can be written beautifully if you know how. And there's lots of great code to learn from in the open-source dotnet core runtime repo and related projects. permalink fedilink source parent hideshow 2 child comments replies: [–] Fiery@lemmy.dbzer0.com 2 points 1 year ago (1 child) Functional programming fixes the problem by simply not making it OO anymore, and while I'm personally a big fan of the paradigm there are situations where an OO approach is preferable (or even only to conform to a project's existing way of doing things). permalink fedilink source parent hideshow 2 child comments replies: [–] kogasa@programming.dev 1 point 1 year ago What I described isn't necessarily functional. This is just a principle for ensuring objects represent clear and well-defined contracts. The idea is that to mutate something, you should own it; that means interfaces / public APIs, which can be called externally, should take immutable arguments. You can still mutate instance members internally because those are owned by the instance. If mutation is really necessary between two objects then it should be coordinated by an object owning them both. permalink fedilink source parent [–] ThirdConsul@lemmy.ml 1 point 1 year ago Oh god, I didn't knew that. That's funny. permalink fedilink source parent [–] MonkderVierte@lemmy.zip 2 points 1 year ago (1 child) Now my brain wants to relate Java somehow to beancounters. permalink fedilink source parent hideshow 2 child comments replies: [–] panda_abyss@lemmy.ca 1 point 1 year ago Well it is owned by Oracle now permalink fedilink source parent
[–] frezik@lemmy.blahaj.zone 16 points 1 year ago (1 child) 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. permalink fedilink source parent hideshow 2 child comments replies: [–] Fiery@lemmy.dbzer0.com 5 points 1 year ago (2 children) Not like C# is all that much better. So much garbage in the fundamentals just because it was done that way at the start and "they can't change it now". The best example is the IList interface. Theoretically this interface exposes both index-based access and collection-like modifications and as such would be perfect in a function if you need those two features on a type. In reality you can't use it as a function parameter because half the official types implementing IList aren't modifiable and throw a runtime error. E.g Arrays permalink fedilink source parent hideshow 4 child comments replies: [–] kogasa@programming.dev 2 points 1 year ago* (1 child) That's a footgun sure but at least you can avoid it once you're aware of the problem. I never write function signatures with mutable interfaces. It's always IEnumerable, IReadOnlyCollection, or IReadOnlyList; otherwise, use a concrete type. The latter is typical for private/protected methods that are called with instance members of a concrete type rather than public interfaces. If you want to mutate an object, you should own it. Public methods are invoked with data not owned by the instance. For example, a lot of extension methods in LINQ have a signature IEnumerable --> IEnumerable, and internally the first thing they do is call .ToList(). The interface makes minimal assumptions about the input data, then puts it into a concrete type you can manipulate efficiently. You can similarly define a method for IReadOnlyList and explicitly make it mutable via .ToList(), rather than use IList and check .IsReadOnly. Both ensure correctness but the former does it at the type level, at design time, instead of relying on runtime checks. C# is old and full of oldness. But it's also an excellent language that can be written beautifully if you know how. And there's lots of great code to learn from in the open-source dotnet core runtime repo and related projects. permalink fedilink source parent hideshow 2 child comments replies: [–] Fiery@lemmy.dbzer0.com 2 points 1 year ago (1 child) Functional programming fixes the problem by simply not making it OO anymore, and while I'm personally a big fan of the paradigm there are situations where an OO approach is preferable (or even only to conform to a project's existing way of doing things). permalink fedilink source parent hideshow 2 child comments replies: [–] kogasa@programming.dev 1 point 1 year ago What I described isn't necessarily functional. This is just a principle for ensuring objects represent clear and well-defined contracts. The idea is that to mutate something, you should own it; that means interfaces / public APIs, which can be called externally, should take immutable arguments. You can still mutate instance members internally because those are owned by the instance. If mutation is really necessary between two objects then it should be coordinated by an object owning them both. permalink fedilink source parent [–] ThirdConsul@lemmy.ml 1 point 1 year ago Oh god, I didn't knew that. That's funny. permalink fedilink source parent
[–] Fiery@lemmy.dbzer0.com 5 points 1 year ago (2 children) Not like C# is all that much better. So much garbage in the fundamentals just because it was done that way at the start and "they can't change it now". The best example is the IList interface. Theoretically this interface exposes both index-based access and collection-like modifications and as such would be perfect in a function if you need those two features on a type. In reality you can't use it as a function parameter because half the official types implementing IList aren't modifiable and throw a runtime error. E.g Arrays permalink fedilink source parent hideshow 4 child comments replies: [–] kogasa@programming.dev 2 points 1 year ago* (1 child) That's a footgun sure but at least you can avoid it once you're aware of the problem. I never write function signatures with mutable interfaces. It's always IEnumerable, IReadOnlyCollection, or IReadOnlyList; otherwise, use a concrete type. The latter is typical for private/protected methods that are called with instance members of a concrete type rather than public interfaces. If you want to mutate an object, you should own it. Public methods are invoked with data not owned by the instance. For example, a lot of extension methods in LINQ have a signature IEnumerable --> IEnumerable, and internally the first thing they do is call .ToList(). The interface makes minimal assumptions about the input data, then puts it into a concrete type you can manipulate efficiently. You can similarly define a method for IReadOnlyList and explicitly make it mutable via .ToList(), rather than use IList and check .IsReadOnly. Both ensure correctness but the former does it at the type level, at design time, instead of relying on runtime checks. C# is old and full of oldness. But it's also an excellent language that can be written beautifully if you know how. And there's lots of great code to learn from in the open-source dotnet core runtime repo and related projects. permalink fedilink source parent hideshow 2 child comments replies: [–] Fiery@lemmy.dbzer0.com 2 points 1 year ago (1 child) Functional programming fixes the problem by simply not making it OO anymore, and while I'm personally a big fan of the paradigm there are situations where an OO approach is preferable (or even only to conform to a project's existing way of doing things). permalink fedilink source parent hideshow 2 child comments replies: [–] kogasa@programming.dev 1 point 1 year ago What I described isn't necessarily functional. This is just a principle for ensuring objects represent clear and well-defined contracts. The idea is that to mutate something, you should own it; that means interfaces / public APIs, which can be called externally, should take immutable arguments. You can still mutate instance members internally because those are owned by the instance. If mutation is really necessary between two objects then it should be coordinated by an object owning them both. permalink fedilink source parent [–] ThirdConsul@lemmy.ml 1 point 1 year ago Oh god, I didn't knew that. That's funny. permalink fedilink source parent
[–] kogasa@programming.dev 2 points 1 year ago* (1 child) That's a footgun sure but at least you can avoid it once you're aware of the problem. I never write function signatures with mutable interfaces. It's always IEnumerable, IReadOnlyCollection, or IReadOnlyList; otherwise, use a concrete type. The latter is typical for private/protected methods that are called with instance members of a concrete type rather than public interfaces. If you want to mutate an object, you should own it. Public methods are invoked with data not owned by the instance. For example, a lot of extension methods in LINQ have a signature IEnumerable --> IEnumerable, and internally the first thing they do is call .ToList(). The interface makes minimal assumptions about the input data, then puts it into a concrete type you can manipulate efficiently. You can similarly define a method for IReadOnlyList and explicitly make it mutable via .ToList(), rather than use IList and check .IsReadOnly. Both ensure correctness but the former does it at the type level, at design time, instead of relying on runtime checks. C# is old and full of oldness. But it's also an excellent language that can be written beautifully if you know how. And there's lots of great code to learn from in the open-source dotnet core runtime repo and related projects. permalink fedilink source parent hideshow 2 child comments replies: [–] Fiery@lemmy.dbzer0.com 2 points 1 year ago (1 child) Functional programming fixes the problem by simply not making it OO anymore, and while I'm personally a big fan of the paradigm there are situations where an OO approach is preferable (or even only to conform to a project's existing way of doing things). permalink fedilink source parent hideshow 2 child comments replies: [–] kogasa@programming.dev 1 point 1 year ago What I described isn't necessarily functional. This is just a principle for ensuring objects represent clear and well-defined contracts. The idea is that to mutate something, you should own it; that means interfaces / public APIs, which can be called externally, should take immutable arguments. You can still mutate instance members internally because those are owned by the instance. If mutation is really necessary between two objects then it should be coordinated by an object owning them both. permalink fedilink source parent
[–] Fiery@lemmy.dbzer0.com 2 points 1 year ago (1 child) Functional programming fixes the problem by simply not making it OO anymore, and while I'm personally a big fan of the paradigm there are situations where an OO approach is preferable (or even only to conform to a project's existing way of doing things). permalink fedilink source parent hideshow 2 child comments replies: [–] kogasa@programming.dev 1 point 1 year ago What I described isn't necessarily functional. This is just a principle for ensuring objects represent clear and well-defined contracts. The idea is that to mutate something, you should own it; that means interfaces / public APIs, which can be called externally, should take immutable arguments. You can still mutate instance members internally because those are owned by the instance. If mutation is really necessary between two objects then it should be coordinated by an object owning them both. permalink fedilink source parent
[–] kogasa@programming.dev 1 point 1 year ago What I described isn't necessarily functional. This is just a principle for ensuring objects represent clear and well-defined contracts. The idea is that to mutate something, you should own it; that means interfaces / public APIs, which can be called externally, should take immutable arguments. You can still mutate instance members internally because those are owned by the instance. If mutation is really necessary between two objects then it should be coordinated by an object owning them both. permalink fedilink source parent
[–] ThirdConsul@lemmy.ml 1 point 1 year ago Oh god, I didn't knew that. That's funny. permalink fedilink source parent
[–] MonkderVierte@lemmy.zip 2 points 1 year ago (1 child) Now my brain wants to relate Java somehow to beancounters. permalink fedilink source parent hideshow 2 child comments replies: [–] panda_abyss@lemmy.ca 1 point 1 year ago Well it is owned by Oracle now permalink fedilink source parent
[–] panda_abyss@lemmy.ca 1 point 1 year ago Well it is owned by Oracle now permalink fedilink source parent
[–] shape_warrior_t@programming.dev 18 points 1 year ago (1 child) 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. permalink fedilink source parent hideshow 2 child comments replies: [–] dejected_warp_core@lemmy.world 8 points 1 year ago (1 child) 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. permalink fedilink source parent hideshow 2 child comments replies: [–] Lightfire228@pawb.social 7 points 1 year ago At least python has a decent runtime typing system JS's type system feels like what you'd get by giving a monkey access to unlimited cocaine and a computer permalink fedilink source parent
[–] dejected_warp_core@lemmy.world 8 points 1 year ago (1 child) 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. permalink fedilink source parent hideshow 2 child comments replies: [–] Lightfire228@pawb.social 7 points 1 year ago At least python has a decent runtime typing system JS's type system feels like what you'd get by giving a monkey access to unlimited cocaine and a computer permalink fedilink source parent
[–] Lightfire228@pawb.social 7 points 1 year ago At least python has a decent runtime typing system JS's type system feels like what you'd get by giving a monkey access to unlimited cocaine and a computer permalink fedilink source parent
[–] PlexSheep@infosec.pub 12 points 1 year ago Having a field called r#self is malicious madness permalink fedilink source parent