[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Python or Perl for a Debian maintainance project?

On Sat, Feb 21, 2004 at 07:25:13PM +0100, Matthias Urlichs wrote:
> Hi, Julian Mehnle wrote:
> > Steve Greenland wrote:
> >> to describe Perl's OOP system as anything except "kludgy and fragile" is
> >> wishful thinking.
> > 
> > I've read that multiple times now.  Unless I do have some reading problem,
> > I haven't seen any founded justification for that assessment, though.
> Well, I do agree with Steve.
> Files, for instance, are objects in Perl. Except when they're GLOBs,
> wait, OK, except when they're references to GLOBs.  :-P  There's no sane
> way (one or two less-than-sane ones, though) to write a program which
> accepts all three of these.

It's your own stupid fault if you use typeglobbed filehandles; there's
no reason for it.

> There's no sensible way to figure out whether
> file-thing A and file-thing B refer to the same file descriptor /
> string-used-as-a-file / whatever.

$a->fileno == $b->fileno

> Arrays and hashes are not objects.

Why should they be?

> Neither are numbers. Oh, wait, you
> can use bignums which happen to _be_ objects, and you can (via tie())
> convince Perl to redirect all references to an array to your object
> instead, but that's not quite the same thing.

...but you don't want to. And making numbers objects is a dumb idea
(bignums are supposed to look like they are *not* objects).

The point of tie is to make objects look like non-objects. Not the
other way around. You seem to have missed that point.

> Perl doesn't have class variables,

Don't be silly, of course it does. It's just a lexical in the class

> or instance methods.

I don't think that actually makes sense in perl. It's an artificial
disctinction used in more limited object systems. But you can write
functions that behave like instance methods and call them instance
methods if you wish. Other people might look at you funny and cross
over to the other side of the street, though.

> In fact you can
> argue that Perl doesn't have classes anyway; it's more like "a reference
> to something which is stamped with a package name, which is where
> functions are looked up if you pretend that you want to call a method".

Classes are a design feature. Not an implementation feature. Define
what it means for a language to "have classes", and justify why
anybody should care about that definition.

  .''`.  ** Debian GNU/Linux ** | Andrew Suffield
 : :' :  http://www.debian.org/ |
 `. `'                          |
   `-             -><-          |

Attachment: signature.asc
Description: Digital signature

Reply to: