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

Replies are listed 'Best First'.
Re^2: OO design: abstract class or can()? by adrianh (Chancellor) on Mar 23, 2007 at 13:11 UTC
So you're proposing something like: `$o->some_method if $o->does( 'SomeTrait' )` [download] ?	[reply] [d/l]
Re^3: OO design: abstract class or can()? by stvn (Monsignor) on Mar 23, 2007 at 15:07 UTC
Just a quick comment. While `does` feels very similar to `can` in this case, it will future-proof things since `does('SomeTrait')` can indicate the ability to do many methods, while `can('some_method')` can only ever indicate one. -stvn	[reply] [d/l] [select]
Re^3: OO design: abstract class or can()? by chromatic (Archbishop) on Mar 23, 2007 at 15:20 UTC
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.)	[reply]
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]