Home Original page

Is classless worth consideration

Dave Brueck dave at pythonapocrypha.com
Fri Apr 30 17:15:27 EDT 2004 
has wrote:
> Peter Hansen <peter at engcorp.com> wrote in message
news:<84Kdnfu3OoN4oA_dRVn-vg at powergate.ca>...
> > Hung Jung Lu wrote:
> >
> > > I have also pointed out previously that
> > > Python uses 5 devices where prototype-based needs only one: (a) class,
> > > (b) instance, (c) module, (d) metaclass, (e) scope. If this is not
> > > hideously baroque, then, Houston, we've got a problem. If you can
> > > really think outside the box, you'd pitch in also: (f) aspect.
> >
> > Well, (c) module is merely a packaging technique, not anything
> > to do specifically with OOP, so it shouldn't appear in a list
> > of "what do you think makes Python's OO model hideously baroque".
>
> Modules are an encapsulation mechanism, just like class instances, so
> I'd say the large and obvious overlap counts as unnecessary
> duplication of functionality that by rights ought to have been
> factored out of the language design early on.

No offsense, but this is faulty logic IMO. Just because two concepts can be
unified under the umbrella of another doesn't necessarily mean that elimination
of one or the other is the "right thing to do" if your goal is to make a good
programming language.

Personally I don't really care much about the discussions about purity or
theoretical language simplicity - the fact of the matter is that having modules
and classes is _useful_. If, under the covers, they are (nearly) identical - so
what? In practice it just so happens that they are handy ways to think about
things (one of the things that annoyed me about Java was that it _didn't_ have
modules).

One of the secrets of good language design is not heading too far down the path
of simplicity for the sake of simplicity. Not only are modules a useful
metaphor in big, real programs, they are useful in one-off scripts/apps where
you don't really care about OO, and they're useful when you're teaching
programming to newbies (they are a handy intermediate step in that they show
the basics of separation of functionality, code reuse, etc. without overloading
the student).

> So I think it's reasonable to count them, especially seeing how proto-OO
languages
> have no problems eliminating them as a distinct type.

It's certainly a matter of taste - for example, some of the Prothon examples
I've seen so far leave me with the impression that they are work-arounds
showing you how to get by without some language construct you really wish you
had - the I-don't-have-a-chisel-so-this-screwdriver-will-do feeling.

Perhaps proto-OO languages work really well in particular problem niches but
are less well-suited for general purpose work.

-Dave
More information about the Python-list mailing list