[Catalyst-dev] Re: Moose + Catalyst port

Aristotle Pagaltzis pagaltzis at gmx.de
Sun Mar 16 13:56:10 GMT 2008


* Jonathan Rockway <jon at jrock.us> [2008-03-16 03:45]:
> First, lexically-scoped subs:
> 
>   my $internal_utility = sub { ... };
> 
>   sub external_interface {
>      my ($self) = @_;
>      $internal_utility->($self, ...);
>   }

Note that you can write that like a regular method call:

    $self->$internal_utility(...);

You basically just switch convention from the common “internal
methods start with an underscore” to “internal methods start with
a dollar sign.”

> The disadvantage here is that subclasses can't do anything with
> these, and testing the internal methods by calling them
> directly is not possible. That can be worked around, perhaps
> with PadWalker.

Or less magically, you can write a meta-object style class method
that returns a hash of private methods. The point is not to make
it impossible to reach them, just to make sure they don’t spill
into any namespace.

> Then I realized that you just don't call set-slot. It's there,
> but you don't have to use it.

Yes, the Perl living room and shotgun argument.

> Private methods are the same way. Don't touch them and they
> won't bite you :)

Sure. We’re not nervous about people who do naughty things
getting what they deserve. Rather, the real problem is the other
way around: the author of a subclass must pay close attention not
to define faux-private methods with names that its superclasses
already use. Worse yet, the maintainer(s) of those superclasses
cannot define new private methods because s/he cannot be sure
that a subclass hasn’t taken that name already.

We all know that lexical scoping is good for variables, and not
because of deliberate interlopers so much as for protection from
accidental collisions. That principle doesn’t lose validity when
the things being named are methods rather than variables.

Regards,
-- 
Aristotle Pagaltzis // <http://plasmasturm.org/>



More information about the Catalyst-dev mailing list