Login | Register For Free | Help
Search for: (Advanced)

Mailing List Archive: Perl: porters

Re: overloading standard subroutines?

 

 

Perl porters RSS feed   Index | Next | Previous | View Threaded


bailey at HMIVAX

Sep 26, 1995, 10:14 AM

Post #1 of 2 (79 views)
Permalink
Re: overloading standard subroutines?

>A simple question: can one overload one of Perl's "standard" subroutines?
>
>For example, in VMSperl (version 5.001, 950727D) the "gmtime" routine doesn't
>work because the corresponding VAXCRTL routine doesn't work. But then
>I write:
>
>sub gmtime {
> local ($t) = @_;
> $t = time() unless defined($t);
> return (localtime($t - $ENV{'SYS$TIMEZONE_DIFFERENTIAL'}));
>}
>
>This works fine (even gets the right answer!), as long as I name it
>something *other* than gmtime. Calls to gmtime seem to use the built-in
>(nonfunctional) routine.
>
>Getting gmtime working right would be nice, as a prerequisite for the
>"timelocal" module if nothing else, but I'm interested in the more general
>question of redefining or overloading the built-in functions as well. Is there
>some OO-type syntax that I'm missing here?

AFAIK, the answer is "not yet", really. There have been a few discussions
on perl5-porters about allowing assignment to the typeglob *CORE::gmtime
to redefine the builtin gmtime operator, but it's not working in any
general sense yet. (I've copied this to p5p in case I've missed something;
I'm sure the real experts will straighten me out.)

For the moment, you have to define a C<sub gmtime { ... }> in each package,
and turn all instances of C<gmtime> into C<&gmtime> or C<gmtime()>.

WRT gmtime() specifically, we can problably cons up a replacement using VMS'
native sys$utc routines. The newest DECCRTL has a working gmtime() as well, I
believe, but we'll still have to put something together to support folks who're
running older versions.

Regards,
Charles Bailey bailey [at] genetics


lwall at scalpel

Sep 26, 1995, 11:05 AM

Post #2 of 2 (76 views)
Permalink
Re: overloading standard subroutines? [In reply to]

: >A simple question: can one overload one of Perl's "standard" subroutines?

We call that overriding. Overloading is something different, and is a form
of disambiguation based on argument type.

: >For example, in VMSperl (version 5.001, 950727D) the "gmtime" routine doesn't
: >work because the corresponding VAXCRTL routine doesn't work. But then
: >I write:
: >
: >sub gmtime {
: > local ($t) = @_;
: > $t = time() unless defined($t);
: > return (localtime($t - $ENV{'SYS$TIMEZONE_DIFFERENTIAL'}));
: >}
: >
: >This works fine (even gets the right answer!), as long as I name it
: >something *other* than gmtime. Calls to gmtime seem to use the built-in
: >(nonfunctional) routine.
: >
: >Getting gmtime working right would be nice, as a prerequisite for the
: >"timelocal" module if nothing else, but I'm interested in the more general
: >question of redefining or overloading the built-in functions as well. Is there
: >some OO-type syntax that I'm missing here?
:
: AFAIK, the answer is "not yet", really. There have been a few discussions
: on perl5-porters about allowing assignment to the typeglob *CORE::gmtime
: to redefine the builtin gmtime operator, but it's not working in any
: general sense yet. (I've copied this to p5p in case I've missed something;
: I'm sure the real experts will straighten me out.)
:
: For the moment, you have to define a C<sub gmtime { ... }> in each package,
: and turn all instances of C<gmtime> into C<&gmtime> or C<gmtime()>.

You don't have to go that far. You can override the majority of builtins
merely by importation. (You can't do it just by defining a subroutine--we
disallowed that because it would break too many old script.) It's true that
you still have to do it for each package, but you shouldn't need to do
anything fancier than

use VMS 'gmtime';

or some such. Then the override is defined only in one place.

If you want to override something in only one package, then it suffices
to pseudo-import the name with "use subs" and then define the function
yourself.

Larry

Perl porters RSS feed   Index | Next | Previous | View Threaded
 
 


Interested in having your list archived? Contact Gossamer Threads
 
  Web Applications & Managed Hosting Powered by Gossamer Threads Inc.