Along those lines, it makes no sense for mix-in classes to inherit
from Object at all -- they're neither expanding on object nor
specializing it.
For example, I'm refactoring my python Graph class so that people can
have different Vertex behaviors by using different composition of
mix-in classes. But instead of letting them figure out the object
inheritence order (so there's no conflicts), I'm going to make some
classes that pre-specify the right ordering for different
combiniations of behaviors.
class Vertex(object):
"""Basic Vertex base class, giving a dictionary of edges.""""
class WVertex(Vertex, weighted_mixin): #the weighted_mixin will
override some of the methods in Vertex.
"""Use this when initializing a Graph class for weighted edges."""
class RWVertex(WVertex, reverse_edge_mixin):
"""Use this class for O(1) access to the edges coming into Vertices."""
class Graph(dict):
def __init__(self, init={}, VertexType=Vertex):
"""Creates a Graph with the specified behaviors within VertexType."""
-
No one has to see the mix-in classes.
I'm inventing a new term for this kind of inheritence: expansion.
I've enclosed one class inside of another, but yet it's not quite
"encapsulation" (in the C++ sense).
Cheers,
Mark J
http://wiki.hackerspaces.org/Hacking_with_the_Tao
On 5/10/15, Mark Rosenblitt-Janssen wrote:
> Here's where this exploration came from. I've (once again) been
> contemplating the OO nature.
>
> It's clear to me that there needs to be a distinction between
> specialization of an object vs. expansion of an object (a new term I'm
> proposing to the OOP lexicon). The latter *adds* more functionality
> (like what everyone does with the Object class), while the former
> changes the behavior of some class for more specific behavior that was
> not programmed in the original class.
>
> It's a difference between, for example, concrete base types and ABCs.
> Python artificially tried to make int inherit from object, just
> because it can, but this is wrong. It`s messed with the Zen-thing.
> "Purity has hammered practicality [like the fact that we actually have
> to work on concrete types in the CPU] into the ground. " (addition
> mine).
>
> Sorry I can't spend more time clarifying. I hope that there's at
> least one person who sees the issue.
>
> Mark
>
>
>
> On 5/10/15, Mark Rosenblitt-Janssen wrote:
>> Here's something that might be wrong in Python (tried on v2.7):
>>
>>>>> class int(str): pass
>>
>>>>> int(3)
>> '3'
>>
>> Mark
>>
>
--
https://mail.python.org/mailman/listinfo/python-list
