what's a proper way to code method synonyms

[leocharre]

I'm doing some poop- What's a proper way to code method synonyms?

I've been doing:

# my imaginary method 
sub get_name {
 my $self = shift;
 $self->author or return;
 return "Your name is ".$self->author ". Hope you like it. ";
}

# my synonym
sub name {
 my $self = shift;
 return $self->get_name;
}

This get's tiresome/unmaintainable with 20+ methods.

What about with strictly procedural - that is.. subroutines.. should it be different? Where can I see some examples of this?
I didn't see much in super search under method synonyms

update

After reading the feedback on this original post- It appears to me that promiscuous use of method synonyms are a sugar cube with a drop of cyanide. Probably won't kill you, will taste like a sweet almond- and will likely make you sick.

[merlyn]

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.

[leocharre]

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?).

[merlyn]

Someone should not *have* to read the documentation to use a module that serves such basic data. Is *one* way to pitch this.

And then if I want to subclass your class, I have to subclass every possible spelling. No thanks. There's no excuse for not reading the docs to determine the right method name. Name them consistent, and I'll only have to learn once.

Not to mention that even if you find five aliases for a method name, I'll type in the sixth. All that effort for nothing.

[planetscape]

Erm... Won't that make for an absolute maintenance nightmare when someone has to go in and clean up code that someone else wrote using every possible variant of every possible method? Such a person might well hunt you down for this... (only half kidding)

HTH,

[Anonymous Monk]

< gross > How about an AUTOLOAD that uses Text::Levenshtein on the symbol table to find the best matching sub < /gross >

[Fletch]

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 ) ) }

[ChemBoy]

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.

[merlyn]

*{$new_method} = sub { my $self = shift; $self->$main_spelling(@_) }

Personally, I'd go with;

*{$new_method} = sub { goto &{$_[0]->can($main_spelling)} }

so that caller() would still work right.

[mreece]

here is one way: *name = \&get_name; works the same with methods and subroutines.