in reply to Re: Re: Re: Re: Re: Re: Why breaking can() is acceptable
in thread Why breaking can() is acceptable

On Class::FlyweightWrapper, the subroutine that you return is the one that is meant to be given the private object, not the public one. Since the caller isn't supposed to have the private object, that should be useless.

Wouldn't the following be sufficient? 

  package Class::FlyweightWrapper;
  ...
  sub can {
    my $self = $object{shift(@_)};
    my ($method_name) = @_;
    my $sub = $self->can($method_name)
      or return;
    sub { $object{shift(@_)}->$method_name( @_ ) }
  }

[download]

Replies are listed 'Best First'.
Re: Re: Re: Re: Re: Re: Re: Re: Why breaking can() is acceptable
by tilly (Archbishop) on Apr 06, 2004 at 19:01 UTC
    No.

    You've not supported calling can() on the package. You've also not supported the correct behaviour of can() on methods that actually were defined directly in the PUBLIC class. Such as the constructor, or (now) can(). (A list to which which the user of the module could choose to add.)

    However you're right that someone who wanted to write the AUTOLOAD and then tried to add can() after the fact likely would implement just that and not notice the omissions. (Nor would the testing mantra help - you can't test cases that you didn't think of. And testing AUTOLOAD is harder than it looks because of how much behaviour even a short AUTOLOAD provides to write tests for.) Which illustrates by example my point that even when people try, they'll repeatedly get it wrong.

[reply]

In Section Meditations