3 ms·

There's a lot of backwards and forwards in the comments. What I'd really like is to test my conjecture - could people post/email me a (< 500 line, ideally not d

There's a lot of backwards and forwards in the comments. What I'd really like is to test my conjecture - could people post/email me a (< 500 line, ideally not deep library code) bit of code that they think is "so innately OO friendly that the conjecture won't hold". Given some examples, I'll do a follow-up blog post.

jayd16 6y ago
How about C#'s Task Parallel Library? There's a lot of complexity that is (imo elegantly) abstracted below the surface with the usage of inheritance, while still remaining very configurable and extendable. I'm not sure how you would go about replicating similar async/await sugar without tying functionality to Task instances but I'd like to see it.
aidenn0 6y ago
How about file-like objects in python? Many file-like interfaces are necessarily stateful, and having the state wrapped in an object that encapsulates the state allows for graceful reuse. As a bonus, there's no need for inheritance in python due to duck typing.
- leontrolski 6y ago
  I think you could be on to something - that feels like an area with tightly coupled state and functionality. (Sorry for spamming this thread with comments like this), but would you mind emailing some example code, and we can test what happens?
- chriszhang 6y ago
  > How about file-like objects in python? Many file-like interfaces are necessarily stateful. Still the state and the functions that operate on them can be separated out. Right? No reason why the state and the functions need to be tied together inside a class.
  - aidenn0 6y ago
    Are you suggesting everything that currently takes a file-loke object "f" instead takes "fstate" "fread" "fwrite" "fclose" "fflush"...?
nicbou 6y ago
What is asserted without evidence can be dismissed without evidence. It's not our job to debunk a poorly formed argument. Regardless: pathlib.Path: - https://docs.python.org/3/library/pathlib.html https://docs.python.org/3/library/pathlib.html Django's class-based views and mixins: - https://docs.djangoproject.com/en/3.1/topics/class-based-views/generic-display/ https://docs.djangoproject.com/en/3.1/topics/class-based-vie... - https://docs.djangoproject.com/en/3.1/topics/class-based-views/mixins/ https://docs.djangoproject.com/en/3.1/topics/class-based-vie... Hell, you don't even need to look into other code. Just use the sample from the article. What if client_a and client_b write to different APIs? One expects authentication, the other has pagination and rate limiting. Actually, one of them returns XML. Their URL structure is completely different. Classes are great when you want a bunch of different things to produce a similar result. You don't care how the client fetches and transforms data, as long as it returns it in a certain format. For example, you might want TwitterTweetSource.get_items() and FacebookPostSource.get_items() to both return a list of Posts that have certain attributes. The implementation details don't matter; you just want these methods to have the same signature, because you call [s.get_posts() for s in source_list]. Maybe you'll add FacebookCommentSource, which reuses the same authentication strategy, but on a different endpoint.
- leontrolski 6y ago
  > What is asserted without evidence can be dismissed without evidence I was hoping the code in the article would form (an admittedly small) piece of evidence. I'd just really like someone to show off a nice neat counter example, that demonstrates the true beauty of Python OO, and is "unrefactorable" to a data types + functions equivalent. Pathlib is a great example, maybe a canonical one, of: > Very occasionally, you come up with a core type that's used so often, it's nice to have the cutesy stuff. Django's class based views I think could probably reasonably refactored into data types + functions. I'm not too au-fait with Django or its internals, but if someone could send me a "demonstration Django clone in 800 lines", I'd give it a go. > What if client_a and client_b write to different APIs? ... Then you use an if statement to split at that point. Again, given a specific toy example, I'm fairly certain a reasonable refactor is possible.
  - 6y ago
tored 6y ago
Honest question, what do you expect OO to solve for you? Things like - Maintainability - Extendibility - Testability - Reusability etc One problem with OO is that you can organize your code in many different OO styles and somewhat depending what you try to achieve you should pick a style matching that. Personally I think your example is not separated enough, - Client configuration - Url construction - Reading data from API - Saving data In the first example everything is mixed up in one class, it is like having a huge main function. I would probably have three different classes to solve that.

jayd16 6y ago

How about C#'s Task Parallel Library? There's a lot of complexity that is (imo elegantly) abstracted below the surface with the usage of inheritance, while still remaining very configurable and extendable. I'm not sure how you would go about replicating similar async/await sugar without tying functionality to Task instances but I'd like to see it.

aidenn0 6y ago

How about file-like objects in python? Many file-like interfaces are necessarily stateful, and having the state wrapped in an object that encapsulates the state allows for graceful reuse. As a bonus, there's no need for inheritance in python due to duck typing.

leontrolski 6y ago
I think you could be on to something - that feels like an area with tightly coupled state and functionality. (Sorry for spamming this thread with comments like this), but would you mind emailing some example code, and we can test what happens?
chriszhang 6y ago
> How about file-like objects in python? Many file-like interfaces are necessarily stateful. Still the state and the functions that operate on them can be separated out. Right? No reason why the state and the functions need to be tied together inside a class.
- aidenn0 6y ago
  Are you suggesting everything that currently takes a file-loke object "f" instead takes "fstate" "fread" "fwrite" "fclose" "fflush"...?

nicbou 6y ago

What is asserted without evidence can be dismissed without evidence. It's not our job to debunk a poorly formed argument. Regardless: pathlib.Path: - https://docs.python.org/3/library/pathlib.html https://docs.python.org/3/library/pathlib.html Django's class-based views and mixins: - https://docs.djangoproject.com/en/3.1/topics/class-based-views/generic-display/ https://docs.djangoproject.com/en/3.1/topics/class-based-vie... - https://docs.djangoproject.com/en/3.1/topics/class-based-views/mixins/ https://docs.djangoproject.com/en/3.1/topics/class-based-vie... Hell, you don't even need to look into other code. Just use the sample from the article. What if client_a and client_b write to different APIs? One expects authentication, the other has pagination and rate limiting. Actually, one of them returns XML. Their URL structure is completely different. Classes are great when you want a bunch of different things to produce a similar result. You don't care how the client fetches and transforms data, as long as it returns it in a certain format. For example, you might want TwitterTweetSource.get_items() and FacebookPostSource.get_items() to both return a list of Posts that have certain attributes. The implementation details don't matter; you just want these methods to have the same signature, because you call [s.get_posts() for s in source_list]. Maybe you'll add FacebookCommentSource, which reuses the same authentication strategy, but on a different endpoint.

leontrolski 6y ago
> What is asserted without evidence can be dismissed without evidence I was hoping the code in the article would form (an admittedly small) piece of evidence. I'd just really like someone to show off a nice neat counter example, that demonstrates the true beauty of Python OO, and is "unrefactorable" to a data types + functions equivalent. Pathlib is a great example, maybe a canonical one, of: > Very occasionally, you come up with a core type that's used so often, it's nice to have the cutesy stuff. Django's class based views I think could probably reasonably refactored into data types + functions. I'm not too au-fait with Django or its internals, but if someone could send me a "demonstration Django clone in 800 lines", I'd give it a go. > What if client_a and client_b write to different APIs? ... Then you use an if statement to split at that point. Again, given a specific toy example, I'm fairly certain a reasonable refactor is possible.
- 6y ago

tored 6y ago

Honest question, what do you expect OO to solve for you? Things like - Maintainability - Extendibility - Testability - Reusability etc One problem with OO is that you can organize your code in many different OO styles and somewhat depending what you try to achieve you should pick a style matching that. Personally I think your example is not separated enough, - Client configuration - Url construction - Reading data from API - Saving data In the first example everything is mixed up in one class, it is like having a huge main function. I would probably have three different classes to solve that.