Migrating to perl?
Quinn Dunkan
quinn at zloty.ugcs.caltech.edu
Fri Jan 5 02:27:39 EST 2001
On Fri, 5 Jan 2001 00:47:32 -0500, Joel Ricker <joejava at dragonat.net> wrote:
>From your examples, Pythons class model is much cleaner. Also if I
>understand your example, variables internal to the object are kept
>internal -- they can't be accessed without a proper method. With perl
>anything goes. There are some techniques to prevent this but it isn't
>definite. Its actually this very topic that made me throw my new OO book
>across the room and subscribed to this newsgroup :)
Well, I hate to disappoint, but python doesn't enforce encapsulation. Just
like it doesn't enforce types---you'll get a runtime error down the line. I
too like the idea of enforced encapsulation, so that attribute accesses are
spelled the same as methods, so I won't have to change client code if I want
to alter the implementation. sather, dylan, and ruby are some languages that
provide automatic accessors. I've discovered, though, that I've never had a
problem with python's direct access. Just use your good judgement---you may
discover that you have a lot of that (which you've just demonstrated by trying
python :) Not that I wouldn't mind if python required accessors and settors,
so long as it generated them automatically, but then there's the other problem
that python method calls are slower than straight attribute access.
>I've mentioned before that I'm real new to OO. How should I approach it in
>Python? Has anyone learned OO just from Python? Or should I study OO
>theory else where and then apply it to Python? I know this is bordering on
>the question of how do I do OO but I really know very little about it...
>enough to know that I can benefit from it and basic ideas. I understand the
>idea of a class and building objects from it but anything beyond that is
>still really new to me. Any suggestions?
Well, here's how I did it: I learned the concepts. Then I thought, "OK,
that's nice. I guess it could theoreticly be useful for somethings, if I
could think of them." Then I started on a project in a procedural style. I
was passing around a bunch of data structures, with a common set of
operations. I had to either have multiple procedures, or one procedure that
dispatched on type. Then I thought: "Hey! Dispatching on type... that's
like a method call!" So I put my data structures into classes.. and things
became much clearer. Later, I was passing a lot of closures around. I wanted
to associate an action with its data. Then I thought: "A method is like a
closure on its first argument!" So I rewrote that data structure as a class.
Before I knew it, I was thinking "f is a message sent to the o object, asking
it to...", insatead of "f is a function that maps o values to...".
I guess this is the type of "semi-OO" learning approach that works very well
in a hybrid language like python, and a smalltalker might have different ideas
of how to learn. But it worked for me, because I could see how it can
actually resolve (some kinds of) problems I run into every day in an elegant
manner.
>I know I have been. Nothing like a friendly newsgroup to convince me to
>switch -- at least take a break from perl for awhile to see how the other
>side lives.
And there's more than two sides! You'll receive recommendations to everything
from lua (very python-like), to ruby (pretty python-like), to haskell
(conceptually somewhat python-like, for being diametrically opposed), and
recently erlang (not much like python at all, from what I can see) here.
There's a bazillion worthy languages out there, and c.l.py seems to be a
pretty cosmopolitan crowd.
More information about the Python-list
mailing list