develooper Front page | perl.perl6.language | Postings from January 2004

RE: A modest question

Thread Previous | Thread Next
Austin Hastings
January 7, 2004 07:48
RE: A modest question
Message ID:

From: chromatic []
> On Tue, 2004-01-06 at 22:26, Austin Hastings wrote:
> > So on the grand balance of utility, what are the metrics that traits are
> > supposed to help improve?
> Two big ones:
> 	- naming collections of behavior that are too fine-grained
> to fit into classes cleanly
> 	- enabling finer-grained code reuse
> Consider a method that needs to print an object.  You might require a
> String:
> 	sub print_it ( String $thingie )
> 	{
> 		print $thingie;
> 	}
> Why does it have to be a String, though?  What prevents it from working
> with anything that can stringify, besides the overly restrictive
> signature?  What if you could say (the Perl 6 equivalent of):
> 	sub print_it ( does Stringify $thingie )
> 	{
> 		print $thingie.stringify();
> 	}
> That's both more general and something more specific.  By asking for
> what you really want, you're not coding everyone else into a corner.

This seems to have some pretty strong AOP implications. I can easily see
wanting to generically extend all classes with a capability (role).

So, first, can I define "inferred" roles? For example:

  role Printable { requires toString(); }

such that any object which has a toString method is considered to C<does
If so, can I use junctions to do so? (requires

Next, is there a good way to aspectify this, so that I can impose it without
having to write code to manipulate the namespace and extend every class?

  class [* isa Object] but= Printable;   # All children of Object are

> Take Mail::SimpleList and Mail::TempAddress, for example.  Both have
> classes that represent individual addresses or mailing lists.  The
> appropriate parent class is Mail::Action::Address, which has the very
> basic data and properties that both subclasses share.
> Both simple lists and temp addresses should contain expiration dates, so
> both classes need some sort of behavior to implement that.
> When you throw another class into the mix, say, Mail::OneWayList, where
> there's no expiration (trust me, even though it's not on the CPAN yet),
> there's a problem.
> I'd like to share code between all three classes that represent aliases
> and Mail::Action::Address is the appropriate place to do that.  I don't
> want to share *all* of the code, though, so I can't really put the
> expiration code in Mail::Action::Address.
> I *could* subclass Mail::Action::Address and make
> Mail::Action::Address::Expires and change the parent class of the temp
> address and the simple list classes, but that's kinda icky as it leads
> to yet another level in the class hierarchy.
> By turning expiration into a role, though, everything can extend
> Mail::Action::Address and only those classes that really need expiration
> can do it -- and they share the code.
> Contrived example?  Maybe.  Maybe not.  Consider further James
> Fitzgibbon's Mail::Action::Role::Purge.  James wanted to extend all
> Mail::Action subclasses to allow purging of expired addresses or lists.
> That's reasonable, but it's not something I wanted to add to
> Mail::Action because it doesn't know anything about expiration.
> So he made it a role and decorates expirable objects with the role and
> can do what he wants there.
> Again, the goals are specificity, genericity, and improved reuse.

Cool, thanks.


Thread Previous | Thread Next Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at | Group listing | About