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

Now if I could convince you to use My instead of MY, your scripts will be slightly easier to translate to Perl 6.

Actually, how about OUR:: instead of My:: - or is that somewhere in Perl 6 too?

Reasoning:

Sound vaguely sane?

Replies are listed 'Best First'.
Re: Re^2: Private method variations
by TimToady (Parson) on Mar 01, 2004 at 17:34 UTC
    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.

[reply]
[d/l]
      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();

      [download]

      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.

[reply]
[d/l]
[select]
        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.
[reply]
[d/l]
[select]
Re: Re^2: Private method variations
by stvn (Monsignor) on Mar 01, 2004 at 17:33 UTC

    Maybe I am being niave but, is there something wrong with MyClass::PRIVATE:: ? It would be the least ambiguous of all IMO. I mean it would be hard to grab the PRIVATE:: root namespace, but if you are using a source filter anyway, you could generate the MyClass::PRIVATE:: "inner"-package with ease.

    -stvn
[reply]
      Maybe I am being niave but, is there something wrong with MyClass::PRIVATE

      Nothing beyond the extra 4 (for OUR::) or 5 (for MY::) characters that you have to type every time you call the method :-)

      I fear I am too lazy to want to type those extra characters that often.

      It also differs a little from the meaning of "private" in some other languages since you can easily get at the method from other classes if you ask for it explicitly - it's just in another package after all.

[reply]
        It also differs a little from the meaning of "private" in some other languages since you can easily get at the method from other classes if you ask for it explicitly - it's just in another package after all.

        Quite true, but do you not intend it to be viewed as "private" ala Java/C++ etc? In which case, the name may actually help to "enforce" your intentions even though the reality is actually different.

        -stvn
[reply]

In Section Meditations