anomaly

[Mark Rosenblitt-Janssen]

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 <dreamingforward at gmail.com> 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 <dreamingforward at gmail.com> wrote:
>> Here's something that might be wrong in Python (tried on v2.7):
>>
>>>>> class int(str): pass
>>
>>>>> int(3)
>> '3'
>>
>> Mark
>>
>