in reply to Private method variations

How is SUPER implemented? I think it would make more sense to leverage that code and make it part of Perl itself.

An alternative I prefer better is to make it an attribute. Something along the lines of: 

sub greet_world : no_override {
    my $self = shift;
    my ($greeting) = @_;

    print "$greeting, world\n";
}

[download]

Of course, I don't know a lot about attributes, but that would make more syntactical sense, to me ...

Update: Would Attribute::Protected do this?

------
We are the carpenters and bricklayers of the Information Age.

Please remember that I'm crufty and crochety. All opinions are purely mine and all code is untested, unless otherwise specified.

Replies are listed 'Best First'.
Re^2: Private method variations
by adrianh (Chancellor) on Mar 01, 2004 at 08:58 UTC
    How is SUPER implemented? I think it would make more sense to leverage that code and make it part of Perl itself.

    I doubt there would be much code to leverage. Beyond the lexical similarity there's not a lot of common ground. SUPER is doing a runtime method lookup, while MY is doing compile-time namespace fiddling.

    An alternative I prefer better is to make it an attribute

    You could use an attribute to wrap a method to check it was only called on objects of a specific type. However this would still leave the method in the same name space, which leads to the original problem of subclasses breaking due to implementation changes in the base class.

    You could also use the attribute, I guess, to mark methods for later transfer to another namespace in an INIT block - but that would still leave the method calls to be dealt with. You'd have to use a source filter for that - or use the full package name of the private namespace which CanBeTedious.

    Of course in Perl 6 it would both trivial (since we have a decent macro system) and unnecessary (since Larry and friends are making what looks to be a very nice OO environment).

[reply]
Re: Re: Private method variations
by flyingmoose (Priest) on Mar 01, 2004 at 05:33 UTC
    Problem is, that is run-time, not compile-time stuff.

    When called from inappropriate classes, those methods throw an exception like foo() is a protected method of Foo!.

    Can't say I like that. I want to know if my system is broken before I happen to stumble across a particular leg of code -- especially if it's not going to be covered very often.

    Yes, some one else is going to chime in and say "Perl OO isn't like that", and I'll say "why shouldn't it be?". Hint: that's a rhetorical question.

[reply]

      I agree with you, that its nice to know at compile time, but perl isn't like tha...

      Yes, some one else is going to chime in and say "Perl OO isn't like that", and I'll say "why shouldn't it be?". Hint: that's a rhetorical question.

      Its not so much that Perl is not like that, its that the more "dynamic" OO languages are not like that. Smalltalk, Python, etc. etc. most of them don't have a concept of public, protected and private either. It's really an idea that is much more acceptable in a more "static" OO language where such "restrictions" are the norm. It's a trade-off really.

      Personally, I am waiting to see how they solve issues like this in the Perl 6 object model. It should be very interesting.

      -stvn
[reply]

In Section Meditations