Re: what's a proper way to code method synonyms
by merlyn (Sage) on Sep 06, 2006 at 14:44 UTC
|
This get's tiresome/unmaintainable with 20+ methods
I think the real question you should ask is "how come I have 20+ methods that need to be aliased like this?".
If it's to support legacy, I'd give you a pass. But if you design it this way out of the box, I'd fail you in a code review.
| [reply] [Watch: Dir/Any] |
|
I'm developing a module CGI::PathRequest (seemed like the best name). It's an object that encapsulates various queries to a resource being accessible in a cgi environment. Usualyl a http accessible file.
You optionally initiate it by passing it a relative path.. And as you query it, it gives you info like relative path, absolute path, prettied up filename, is_text, is_dir, is_image, get an excerpt (if a text file) some other things that are really useful to me when I code CGI.
I want to give a coder using this module a lot of freedom. I want it to be intuitive.
How should someone query the instance for an absolute path? The more conservative way is: $object->get_absolute_path , but it could be more intuitive for someone to ask for $file->abs_path - so I have both. Someone should not *have* to read the documentation to use a module that serves such basic data. Is *one* way to pitch this.
It doesn't *need* to have that many synonims. I remember reading somewhere that a good application is liberal about what it accepts and conservative about what it outputs. I am trying to be liberal about what it accepts- about how you can ask it questions.
Yes, they can look at the documentation (which i wrote first).. But I want it to be intuitive. I almost would like to be able to ask $object->get_me_the_absolute_path and let the thing resolve by itself what the heck i want ( i know there's a module for that.. was it Sam Treggar?).
| [reply] [Watch: Dir/Any] |
|
| [reply] [Watch: Dir/Any] |
|
|
| [reply] [Watch: Dir/Any] |
|
|
< gross > How about an AUTOLOAD that uses Text::Levenshtein on the symbol table to find the best matching sub < /gross >
| [reply] [Watch: Dir/Any] |
|
Re: what's a proper way to code method synonyms
by Fletch (Bishop) on Sep 06, 2006 at 14:03 UTC
|
sub real_method { ... }
sub real_sub { ... }
{ no strict 'refs'; *{$_} = \&real_method for ( qw( foo bar baz blort
+) ) }
{ no strict 'refs'; *{$_} = \&real_sub for ( qw( quux pony ) ) }
| [reply] [Watch: Dir/Any] [d/l] |
|
Though I share merlyn's reservations about the idea in general, I think it's worth pointing out that the OP's aliasing method doesn't break inheritance, but this one does: if a subclass overrides the main spelling of the method, the alternate spellings should also be directed to the overridden method, rather than bypassing it. As an alternative approach that combines something approaching safety with reasonable typing economy, I'd try something like this:
_make_aliases('real_method',qw(foo bar baz blort));
sub _make_aliases {
no strict 'refs';
my ($main_spelling,@alternates) = @_;
foreach my $new_method (@alternates) {
*{$new_method} = sub { my $self = shift; $self->$main_spelling
+(@_) }
}
}
This approach should (I haven't tested) let subclasses safely ignore the aliasing entirely, and just override the main method—though any diagnostic messages may still be a bit confusing. And it still provides the economy of keystrokes that the OP was looking for.
If God had meant us to fly, he would *never* have given us the railroads. --Michael Flanders
| [reply] [Watch: Dir/Any] [d/l] |
|
*{$new_method} = sub { goto &{$_[0]->can($main_spelling)} }
so that caller() would still work right.
| [reply] [Watch: Dir/Any] [d/l] [select] |
Re: what's a proper way to code method synonyms
by mreece (Friar) on Sep 06, 2006 at 14:52 UTC
|
here is one way: *name = \&get_name;
works the same with methods and subroutines.
| [reply] [Watch: Dir/Any] [d/l] |