note
jonadab
<blockquote>Quite simply, all classes in perl inherit from UNIVERSAL. UNIVERSAL implements can.</blockquote>
<p>This is an interesting statement. The index of my
Camel book (2nd ed) does not list can at all and
contains only one entry for UNIVERSAL, which points
to page 293, where I find the following quote
(emphasis mine):
</p>
<blockquote>If neither a method nor an AUTOLOAD routine
is found in @ISA, then one last, desperate try is
made for the method (or an AUTOLOAD routine) in the
special predefined class called UNIVERSAL.
<em>This package does not initially contain any
definitions</em> (although see CPAN for some), but
you may place your "last-ditch" methods there.
</blockquote>
<p>This not only doesn't support your assertion but
seems on the face of it to directly contradict what
you were saying. How can UNIVERSAL implement can,
and require that all derived objects (i.e., all
objects) not break that, if UNIVERSAL does not
initially contain any definitions? Further,
NOTHING is said here about any obligations that any
module has to provide or support any particular
method.
</p>
<p>Granted, what I have is not the latest edition, but
none of the reviews I have read of the third edition
have said anything about the new edition containing
important information about fundamental changes to
the language that every Perl programmer must know,
nor is it advertised that way by the author or by
the publisher. It's simply the next edition of the
book, no more.
I did see some reviews praising the addition of
numerous new examples, but nothing that seemed to
indicate to me that if I program according to the
second edition I'll break things. To be perfectly
honest, I've got a lot of things marked in my camel
(not least, little tabs on the sides of the pages
to mark where certain sections start so I can quickly
flip e.g. to the section on special variables), and
not wanting to redo all of that right away I was
going to wait for the fourth edition, which hopefully
will cover Perl6, before upgrading. Perhaps you
could quote me just the paragraph of the 3rd edition
that explains why every object is required to
support the can method.
</p>
<p><strong>update:</strong> In the light of morning,
the next paragraph seems harsh to me. I didn't
mean it that way. I'm not going to edit it out,
though, because the reply wouldn't make (as much)
sense then. (And [chromatic], I recognize your
reputation, but you hadn't yet come out to say
anything in the thread when I wrote this.)
</p>
<p>I'm interested in hearing about the merits of can,
the practical reasons why it's a useful thing for
modules to support, even if the module author does
not personally use it. I'm somewhat less interested
in hearing you just tell me (in so many words)
"This is just required". I <em>might</em> accept
that coming from someone who is on a first-name basis
with Larry's wife, but I am dubious as to what
authority <strong>[stvn|you]</strong> have to make
up requirements for all Perl modules to adhere to.
</p>
<div class="pmsig">
<div class="pmsig-230012">
<hr />
<tt>;$;=sub{$/};@;=map{my($a,$b)=($_,$;);$;=sub{$a.$b->()}}</tt>
<tt>split//,".rekcah lreP rehtona tsuJ";$\=$;[-1]->();print</tt>
</div></div>
342804
342971