Beefy Boxes and Bandwidth Generously Provided by pair Networks
XP is just a number
 
PerlMonks  

Re: Re^2: Private method variations

by TimToady (Parson)
on Mar 01, 2004 at 17:34 UTC ( #332988=note: print w/ replies, xml ) Need Help??


in reply to Re^2: Private method variations
in thread Private method variations

Actually, how about OUR:: instead of My:: - or is that somewhere in Perl 6 too?
Well, I actually thought about that one, but didn't think you'd go for something even longer. :-)

As for whether it's in Perl 6, the only answer I can give is: "not yet". But by and large all-uppercase names are kinda sorta reserved for Perl to grow into. More or less. So maybe Our:: would be a better choice.


Comment on Re: Re^2: Private method variations
Download Code
Replies are listed 'Best First'.
Re^4: Private method variations
by adrianh (Chancellor) on Mar 01, 2004 at 22:29 UTC
    Well, I actually thought about that one, but didn't think you'd go for something even longer. :-)

    One extra character I can probably cope with :-)

    As for whether it's in Perl 6, the only answer I can give is: "not yet". But by and large all-uppercase names are kinda sorta reserved for Perl to grow into. More or less. So maybe Our:: would be a better choice.

    Your right that from an upward compatibility point of view Our:: (or My::) is clearly a better choice.

    The downside is that it then looks so much like a normal fully qualified method call. Thanks to NEXT and SUPER using UPPERCASE provides a handy cue to the developer that some magic is happening.

    Hmmm... Swings or roundabouts. Roundabouts or swings.

    Oooohhh! Just had a sneaky idea.

    "_" seems to be a valid package name. Is:

    sub _::secret { ... }; $self->_::secret();

    to evil? Even shorter that MY::, doesn't look like a "normal" fully qualified method call and we get the whole "_" thang that people are already used to.

      Well, package _ will probably be the current package, just as $_ is the current topic and &_ is the current sub. Also, in some cases, @_ is still the current argument list, and %_ will often be the current options.
        Well, package _ will probably be the current package

        Phoey :-)

        Ah well. Now leaning toward one of:

        $self->OUR::private_method $self->__::private_method $self->_MY::private_method

        All screams of "Good grief that's too ugly for words" welcome!

        Here's a thought - offload the naming decision onto the developer:

        package Foo; use Package::Prefix Our => 'Foo::Our'; sub new { my $self = bless {}, shift; $self->Our::init(@_); return $self; }; sub Our::init { ... };

        which would have the affect of defining/calling Foo::Our::init. This could have other convenient uses:

        use Package::Prefix VLPN => 'Very::Long::Package::Name'; use VLPN::Foo; use VLPN::Bar; my $foo = VLPN::Foo->new(); my $bar = VLPN::Bar->new();
        &_ is the current sub? Cool! That means I can recurse, tail-eliminatively, with
        goto &_
        rather than
        goto &{ (caller(0))[3] };
        Well, I view it as a significant bene, anyway.

        But then, you probably have better things in mind for TRE...

        jdporter
        The 6th Rule of Perl Club is -- There is no Rule #6.

Log In?
Username:
Password:

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://332988]
help
Chatterbox?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others meditating upon the Monastery: (6)
As of 2015-07-30 06:18 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    The top three priorities of my open tasks are (in descending order of likelihood to be worked on) ...









    Results (270 votes), past polls