develooper Front page | perl.perl6.language | Postings from May 2005

Re: Virtual methods

Thread Previous | Thread Next
Piers Cawley
May 25, 2005 06:11
Re: Virtual methods
Message ID:
Aaron Sherman <> writes:

> On Wed, 2005-05-18 at 10:51, Luke Palmer wrote:
>> Except that mixins like this always treat things as "virtual". 
>> Whenever you mixin a role at runtime, Perl creates an empty, anonymous
>> subclass of the current class and mixes the role in that class.  Since
>> roles beat superclasses, you'll always override your own methods.
> Ok, good point (I've even pointed that out to others before, and I
> missed it)...
> I know that's the way it works, but now it's really bothering me.
> There are many gotchas that fall out of that. For example, you might
> have a special role that overrides .print to handle structured data, so
> your code says:
> 	my Foo $obj;
> 	given $obj {
> 		when StructuredPrintRole {
> 			# Someone's already taken care of it, possibly
> 			# adding a more specialized role, so leave it
> 			# alone.
> 		}
> 		default {
> 			# Add in a boring default handler
> 			$obj does StructuredPrintRole
> 		}
> 	}
> 	$obj.print($structured_data);
> Woefully, you lose is Foo happens to be DECLARED with
> StructuredPrintRole, and it overrode print. But, if it just inherited a
> print(), then it works. In other words, this code will mysteriously fail
> the second someone innocently adds a print method to Foo!
> Action at a distance... my head hurts.

Aaron, you do realise that that's quite obscene code don't you? I mean, you're
doing a case statement based on the type of its topic, and to compound the
evils, you're changing how your topic's print method works *everywhere* simply
to get your 'special' print behaviour. If you must do something like this (and
call it print), then write it as a multimethod or something.

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