You may have noticed that in all the responses so far nobody used function protoypes. They dont do what you probably think they do and you should avoid them like the plague. They are one of Perls many "dont use this until you know why this should be used, if ever" features. Specifically in your case
sub search($) { ... }
is both misleading and IMO wrong. Methods _always_ take at least one parameter ($self) and prototypes are ignored when a subroutine is invoked via a method call. So they wouldnt directly break any OO code involved, but it is common knowledge that
$obj->method($parameter);
is more or less equivelent to
PACKAGE::method($obj,$parameter)
But the prototype you have used would prevent the second call from being made. This will only annoy the power user who deliberately did this for some presumably good reason, and really does no good so you should just drop the prototype.
sub search{ ... }
Or am I maybe thinking about this all wrong?
Quite possibly yes. Concern over private data managment is much more important in languages where you are linking to precompiled libraries that you do not have the code for. In perl its usually quite sufficient to mark data as private by some form of notational convention, and then leave it at that. The issue in Perl for private data is mostly to make accidental corruption unlikely not to make the data 100% absolutely unaccessable by external entitities. (Which is in fact more or less impossible, given the various devious modules out there.)
In reply to Re: Package-Level Variables
by demerphq
in thread Package-Level Variables
by Anonymous Monk
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |