Hello gzartman,
Thanks for adding the <code> tags to the OP.
If you really need do need to call doesUserExist() from the parent class (which I doubt), you’ll have to give the parent class a default version of this method, then override it in the child class(es) as needed. For example (untested):
package esmith::AD; sub doesUserExist { return 0; # default answer: 'No' } package esmith::AD::User; use List::Util qw( any ); my @user_names; # class variable sub doesUserExist { my ($self) = @_; # assuming that $self is a hash reference return any { $_ eq $self->{Name} } @user_names; }
But I still don’t see what you gain by this. In your example, the “lazy” code is no shorter than the “proper” code, so why not just use the latter?
It occurs to me that you might, just possibly, be looking for some form of factory, but again this seems like overkill unless you have a good reason for it?
Update: The test for whether or not a new user already exists should, of course, be done in the constructor.
Hope that helps,
| Athanasius <°(((>< contra mundum | Iustus alius egestas vitae, eros Piratica, |
In reply to Re^3: Method of child module called by parent
by Athanasius
in thread Method of child module called by parent
by gzartman
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |