Re^3: OO design: abstract class or can()?

Exactly.

It's also a nice bit of future-proofing in case Perl ever gets multi-dispatch... and that day may be closer than many people think. (I mean dispatch based on role, not structural type.)

Comment on Re^3: OO design: abstract class or can()?

Replies are listed 'Best First'.
Re^4: OO design: abstract class or can()? by adrianh (Chancellor) on Mar 24, 2007 at 20:52 UTC
It's also a nice bit of future-proofing in case Perl ever gets multi-dispatch... and that day may be closer than many people think. (I mean dispatch based on role, not structural type.) Meh. Still think it would be simpler without the "if". Spinning out the calling behaviour from the thing being called feels odd to me. If the calling is independent of the class then something AOPish would seem appropriate. If not then having e the base class have that trait with a null method rather than have a condition on something that may not be present seems cleaner to me.	[reply]

Replies are listed 'Best First'.

Re^4: OO design: abstract class or can()?
by adrianh (Chancellor) on Mar 24, 2007 at 20:52 UTC

It's also a nice bit of future-proofing in case Perl ever gets multi-dispatch... and that day may be closer than many people think. (I mean dispatch based on role, not structural type.)

Meh. Still think it would be simpler without the "if". Spinning out the calling behaviour from the thing being called feels odd to me.

If the calling is independent of the class then something AOPish would seem appropriate. If not then having e the base class have that trait with a null method rather than have a condition on something that may not be present seems cleaner to me.

[reply]