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