On Monday, May 11, 2015 at 10:49:01 AM UTC-5, Skip Montanaro wrote:
> On Mon, May 11, 2015 at 10:11 AM, zipher <dreamingforw...@gmail.com> wrote:
> > I also bought the idea of everything as an object, it has a unbeatable
> > purity to it. But we won't ever get to the point were OOP is like the
> > purity of math because the greatest utility of OOP is working with
> > real-world data. And that real-world puts bounds on the otherwise abstract
> > purity in which a language is theoretically capable.
>
> Did someone here say it would? Sure, OOP isn't as pure as math, but
> most object-oriented languages aren't pure OO languages, either.
SKip, it's fine to have a loose definition of things in a language when you're
not sure where you want it to go. I think taking Python into the land of
"everything is an object" was a neat exploration. I even supported it. But,
now that I want to create a data ecosystem, sloppiness in design criteria or
inadequacies in implementation gets exercised. Perhaps it won't be Python's
goals, but I would argue that it's the best direction for Python.
These aren't failings of the dev-team either -- no one's done this before.
There are some attempts like CORBA, but either they remained in proprietary
domains or they simply weren't capable of scaling to every kind of data. I've,
in fact, had to invent a new data structure to do it, a data structure I'm
implementing in Python and where the issue of the *nature* of OOP came to the
fore.
For example, have you ever contemplated this:
class WeightedVertex(vertex_common(Vertex(dict))):
"""test class"""
That currently isn't valid Python code, but the idea is that I'm making
composite objects that expand one upon the other -- another basic idea in the
realm of theoretical OOP that this boneheaded community couldn't wrap it's head
around.
Anyway, I'm also saying that it's better to have real design goals when such
noble goals can be made, rather than be content with a sloppy flexibility.
> The practicality side of things suggests that even though
> everything-is-an-object isn't perfect, it may be good enough.
> People/projects/companies generally can't afford to follow every
> change that blows through their environment.
True. Which is why theoretical CS exists -- to find deeper and better
abstractions to encompass everything you want to do. It started with
variables, then linked lists, then trees, then graphs and I'm taking that
trajectory to it's end point. It's real Computer Science. Most people here
haven't seemed to understand the power of Graphs yet, or perhaps they just
can't agree upon an API so leave out such a powerful data structure. I'm
currently refactoring my own implementation, so that it could be considered for
inclusion in the collections module.
Mark
P.S. Sorry for the "boneheaded" insult -- I get called anything from a troll to
a drug addict around here.
--
https://mail.python.org/mailman/listinfo/python-list
