Do I *have* to use 'OOP' to use modules?

[Ilya Zakharevich]

[A complimentary Cc of this posting was sent to
Abigail

__ P.S. Recall that Abigail insisted that attributes should be present
__ in the core, and I fail to see why this should not be delegated
__ to a module.

I couldn't give a rats ass whether it's core or a module.

Probably then it was some different gal who posted:

------
() I'd be interested to hear why you think OO Perl is not worth bothering with.
OOP doesn't have object attributes natively.
------

My point is simple: if attributes were REALLY important to somebody,
then this somebody would spend a couple of hours, and would implement
a module which enables attributes. (Out-of-band storage is not hard.)

Myself, I never needed attributes that badly.

Hope this helps,
Ilya

 

[Arved Sandstrom]

Arved Sandstrom ([email protected]) wrote on MMMMDCCCXXIX
,, > I'm just amazed that people call the absence of elementary construct
,, > (given that you've decided to support OO in the language) a
*feature*.
,, > I've never heard anyone advocate Java or C for their lack of native
,, > support for regular expressions or hashes, but people keep
considering
,, > the lack of support for object attributes as the best thing since
sliced
,, > bread.
,,
,, I don't think Perl is that bad. I fall very strongly on the side of
those
,, who say that it's a knowledgeable programmer who should follow a
contract,
,, not the language that imposes the contract on him or her. Not only
that, but
,, I expect knowledgeable user of my classes, provided that I document
them.
,, There are enough, fairly simple, safeguards in Perl OOP to ensure that
if a
,, user of an OOP module wants to do something that they oughtn't do,
they put
,, some effort into discovering how to do what they shouldn't. And isn't
that
,, really the basic issue?

It's not about following contracts.

Well, it is. If you don't you get bitten, and if you do, well, you'll get
bitten less.

Heh, if you follow contracts, memory management is easy too, and
there won't be memory leaks. Should be then bemoan Perl doing
memory management for us and robbing us from the freedom malloc
and pointers give us?

Not at all - the bemoaning bit, I mean. I'm surely the better for having had
to worry about memory issues (not just pointers but tiny amounts of memory)
back when. Doesn't mean I want to spend quite as much time worrying about it
now (although I do when it's warranted).

No, it turns out that for many programmers, memory management isn't
easy. Having perl do the memory management for you not only reduces
the number of memory management related bugs in the programs, it only
reduces the amount of code a programmer has to write.

I'm an experienced (and I'd like to think a good) programmer - *I* don't
find memory management easy.

If Larry hadn't decide to make OOP an exercise in minimalism and just
had given us attributes, we wouldn't have had the problems we have
now (no compile time checks, unintended clashes, etc), and we could
be even more productive because we would have to write less code.

I will take your word for it re problems. I'm the only guy I personally
know who uses Perl, and I haven't had these problems. I'd already done OOP
in a couple of other languages before Perl 5 happened, and I suppose I used
Perl OOP carefully as a result. As a set of one I am probably not a good
example.

AHS