Hang on I guess I understand what it is you are trying to do...
You want: goto &CORE::return; to work like it reads.
Now my question to you is how does this read to you because what I am
reading in the perlsub about this stuff is the following.
Overriding Built-in Functions
Many built-in functions may be overridden, though this should be tried only
occasionally and for good reason. Typically this might be done by a package
attempting to emulate missing built-in functionality on a non-Unix system.
Overriding may be done only by importing the name from a module at compile
time--ordinary predeclaration isn't good enough. However, the use subs
pragma lets you, in effect, predeclare subs via the import syntax, and these
names may then override built-in ones:
use subs 'chdir', 'chroot', 'chmod', 'chown';
chdir $somewhere;
sub chdir { ... }
To unambiguously refer to the built-in form, precede the built-in name with
the special package qualifier CORE:: . For example, saying CORE::open()
always refers to the built-in open(), even if the current package has
imported some other subroutine called &open() from elsewhere. *Even though
it looks like a regular function call, it isn't: you can't take a reference
to it, such as the incorrect \&CORE::open might appear to produce.*
This leads me to think that what ever this might read to to you does not do
what you are expecting it to do
On 11/28/06, JupiterHost.Net <[EMAIL PROTECTED]> wrote:
Thanks to everyone for their feedback, I understand how to do basic
logic and control flow, what I'm really looking for is how to get
goto &CORE::return;
to work like it reads.
>>>> log_error_and_return($error, @return) if $whatever;
>
> Close.... you want
>
> return log_and_go_home($error, @return) if $whatever;
No :) again I want:
goto &CORE::return;
to work like it reads.
To avoid ambiguity, I'd consistently name the function: carp_return()
for example so you can look at it and go "Oh it looks like it carp()s
first and then returns" this way you can cut down on using the same
logic over and over and over and make it easier to maintain.
Again, as an illustration:
Imagine:
if($whatever) {
carp "Oops: $!";
return;
}
You do that basic thing several times in that funtion, and that in
several functions, in several moduels and script. Say a total of 100
times.
now say you want to add a date stamp to every carp in that sitauation.
Now you have to add it to 100 places, instead of:
But if you could do this:
return_carp(...) if $whatever;
the first time around then you could have 10000 places it gets used in
your app and still only change it in one place. And its pretty
unambiguous IMHO.
Next imagine the stamp it gets is changed format, again you need to find
and update 100 (or are there more now than there where a few weeks ago
when you first added the stamp?) places instead of one which addresses
all concerns :)
So any ideas about how to get:
goto &CORE::return;
to work like it reads.
--
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
<http://learn.perl.org/> < http://learn.perl.org/first-response>
