[Edu-sig] re: Terminology question: just operator overriding?

[Kirby Urner]

At 02:59 PM 6/30/2003 -0400, Arthur wrote:
>Kirby writes -
>
> > Agreed.  It's one thing to be a useful paradigm, another thing to claim
> > to be THE paradigm.  No need to get too doctrinaire.
>
>In fairness to Python, perhaps you should at least give some play to its
>multi-paradigm approach.  Just so people don't confuse it with being
>religiously OO, as for example, Ruby or Smalltalk seem to be.  Talking


Also Java.

I understand that in Perl the class definition is really synonymous
with the module defining it.  In Python, a module as similar to a
class, in that we use dot notation to access its contents.  There's
a dictionary involved.  But there's no subclassing of modules.

>through my hat, BTW, if it isn't clear - that is, considering the depth of
>my undersanding of these issues and my experience with Smalltalk and Ruby.

In Smalltalk, as I understand it, there's no direct access to any of
what we'd call a property.  The interface of an object to the outer
world is methods and that's it.

I've started through the Ruby tutorial a few times.  I'm sort of like
Eckel here -- it's not enough better/different from Python to
attract really sustained interest, whereas a language as different
as J... Bruce hadn't heard of J when I mentioned it during his
presentation to PORPIG.


>The fact is that since Python is my major language, the distinction between
>programming paradigms is not a very useful paradigm with which to concern
>onceself.  The best way to get from Point A to Point B, via Python's
>facilities, is the more useful question.  What paradigm borders I cross in
>the process is not something with which I concern myself (or truly
>understand). If I had more trouble finding my way from A to B - in a way
>that someone following after me would have difficulty following - I would
>then concern myself more with why that might be. And think more, perhaps,
>about programming paradigms. At the level at which I am working, at least, I
>don't see the issue arising.

Makes sense.

What I like about Python is how easy it makes the class idea.  You
don't need to consider it an advanced topic.  You can define
functions in the usual fashion, and interact with them in the
shell.  Then, if you like, you can bundle them such that they're
presented through a class.

For example, one kind of math object I *do* get into in my OSCON
slides is the permutation.  A permutation is a mapping of elements
to the same elements in a different order (surjective and onto, as
the math heads like to say).  Take a deck of cards...  Anyway,
there's a meaning for multiplication here, in that if one permuation
takes you from A to B, and another from B to C, then their product
takes you directly from A to C.  I develop that as a function at
the module level, then invoke it internally to a class definition.
The pattern is like this:

-------- Module -------------

   def compose(map1, map2):
       ...
       return map3

   class Permutation(object):
       ...
       def __mul__(self):
          return Permutation(compose(self.amap, other.amap))

------------------------------

In other words, the class definition wraps first class
functions without bothering to rewrite them.  It's because
Python allows first class functions, not just classes,
that we're able to do this.


>My prejudice toward using OOP  concepts was probably just a function of the
>fact that it was a natural fit for much of what I was doing and how I was
>thinking about what I was doing.

I'm glad you were in the right frame of mind at the right
time.  I don't think there's anything quite like PyGeo out there.
It's still too new to have imitators.  Is it explicitly GPL'd?
I don't remember.  I think you'd be pleased if some 15 year old
started hacking into it, yes?

>Parathentically, the difficulty with OOP is spoken about, in things I have
>stumbled across, as a Circle and Ellipse problem (I think I have this
>right). Being a form of the Chicken and Egg problem.

I'm not familiar with this particular critique.  So I'll take
the bait.  Seems the ellipse would be the more general case, with
the circle being a special case of ellipse, kind of like the
square is a special case of rectangle.  In the typical Venn
Diagram, the squares go inside the rectangles, so circles
should go inside the ellipses.

>Interestingly, to me, thinking in terms of Projective Geoemetry, the issue
>evaporates.  Since they the Circle and Ellipse are projectively equivalent.
>And one would not expect to be able to derive one from the other. They are
>the same thing, different spelling.
>
>Art

Ah so.  So maybe it's not an issue of deciding which inherits
from which.  There's only one class here.  Likewise with the
triangle.  Can I get any triangle I want from the equilateral,
depending on how I project?  I'm experiencing an upwelling of
ignorance re something so basic, turned spontaneously to Google,
only to become side-tracked by
http://www.geocities.com/moonhoabinh/chatter.html ...

Perhaps you have the time to give us some pointers re triangles
in projective geometry.  Any PyGeos already done on that topic?

Kirby