On Wed, Jan 14, 2009 at 7:57 PM, Mark Miesfeld <miesf...@gmail.com> wrote: > On Wed, Jan 14, 2009 at 6:54 PM, Rick McGuire <object.r...@gmail.com> wrote: > >> Well, the best design pattern for something like this would be not do >> the test for the control type, but have a method call at the point >> where you need to distinguish between the objects and have the >> dialogcontrol override that method to produce the different behaviour.
Going back to this a bit. (I'd really like to learn more about good object orientated design. And have been passing up a good opportunity by not asking more questions. <grin>) Here we have this existing design ::class WindowBase public mixinclass object ::class PlainBaseDialog public ... inherit WindowBase ::class DialogControl public ... inherit WindowBase The implementation of getTextSize() works fine as long as the object is either a dialog control or a dialog. But what if a user who doesn't understand the internals well does something like this: ::class MyMenu public subclass object inherit WindowBase menu = .MyMenu~new(...) size = menu~getTextSize(...) Now, the implementation of getTextSize() can't possibly work. That was the situation I was trying to avoid by doing something like: if self not PlainBaseDialog and self not DialogControl then raise syntax exception Then if the user did inherit from WindowBase he couldn't call getTextSize(), he would need to over-ride it with his own implementation if he wanted that method. Should you just trust the user of the classes to not do something foolish, or ... ? -- Mark Miesfeld ------------------------------------------------------------------------------ This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword _______________________________________________ Oorexx-devel mailing list Oorexx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/oorexx-devel
