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