Re: method aliases with goto(&NAME)

[sundialsvc4]

“Scary” is the ultimate under-statement.   “Unmaintainable” is its second cousin.

You probably have a short-list of possibilities where this code can actually “go to.”   Put this into the code such that it cannot go anywhere else without dieing.   For example, return a string or a constant, then use a if {goto} elsif {goto} else {die} construct.   It still sucks but it sucks slightly less.   Now, you do not have to “look somewhere far-away to see what it is supposed to be doing, then cross-your-fingers to see if it actually does it.”   That’s exactly the sort of thing that causes pagers to go-off at 3AM.

[tobyink]

You might be misunderstanding what...

goto(&current_method);

... does. It doesn't execute &current_method, and then go to whatever label was returned from &current_method. It just goes to &current_method. It's not scary; it's not unmaintainable; it's just a tail call.

From perlfunc (my emphasis):

The goto-&NAME form is quite different from the other forms of goto. In fact, it isn't a goto in the normal sense at all, and doesn't have the stigma associated with other gotos. Instead, it exits the current subroutine (losing any changes set by local()) and immediately calls in its place the named subroutine using the current value of @_. This is used by AUTOLOAD subroutines that wish to load another subroutine and then pretend that the other subroutine had been called in the first place (except that any modifications to @_ in the current subroutine are propagated to the other subroutine.) After the goto, not even caller will be able to tell that this routine was called first.

[Anonymous Monk]

“Scary” is the ultimate under-statement. “Unmaintainable” is its second cousin. ...

Cryptic advice -- no friend to clarity and understanding