Thanks James, Tobias, Roger, and Randy, for your advice. In summary, creation of a "Formatter" object that acts upon a Table object seems to be the Right Thing to do. I will create an abstract base class "My::Table::Formatter" that is to be subclassed by My::Table::Formatter::HTML and other "plugins", and these plugins will implement an interface with a single format() method that acts on a My::Table. And since all the plugins implement the same interface, I can hide this additional complexity from the My::Table module user by creating a loader like James proposed.
Does what I want it to do in proper OO fashion! Thanks again all. -- Mark Thomas [EMAIL PROTECTED] Internet Systems Architect User Technology Associates, Inc. $_=q;KvtuyboopuifeyQQfeemyibdlfee;; y.e.s. ;y+B-x+A-w+s; ;y;y; ;;print;; > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] > Sent: Friday, April 04, 2003 11:37 AM > To: [EMAIL PROTECTED]; [EMAIL PROTECTED] > Subject: RE: Perl OO Question: subclass using parent object's > methods, not ove rridden methods? > > > > -----Original Message----- > > From: Thomas, Mark - BLS CTR [mailto:[EMAIL PROTECTED] > > Sent: Friday, April 04, 2003 11:28 AM > > To: Tillman, James; Thomas, Mark - BLS CTR; > > [EMAIL PROTECTED] > > Subject: RE: Perl OO Question: subclass using parent > object's methods, > > not ove rridden methods? > > > > > > > I think, perhaps, a little better description of > > > what you're > > > trying to accomplish with all this OOP might help others give > > > you better > > > advice. Maybe a high-level description of what's desired and > > > what made you try OO in the first place? > > > > OK, let me back up a little and give you some background. > > > > [...] > > > > > Seemed straightforward at first, but the problem I'm running > > into is that > > the html() method refers to a few "private methods" > > ($self->_encode($str)) > > that are My::Table object methods. When I move this into > > Table::Formatter::HTML, the $self still refers to My::Table > > unless I first > > bless($self) into Table::Formatter::HTML. > > > > Does this help? > > Yes. But it basically confirms what I thought you were > trying to do. The solution that offered to you previously > should work just fine for this. The "plugins" you are > talking about would be your "My::Table::HTML" module and the > ASCII and PDF ones. The suggestion from someone else on this > list to use a common base class for these was a very good > one. I've done just this kind of thing before and it works > beautifully. > > Instead of having the My::Table object contain the encoding > logic for the strings, you MUST move that code into your > formatter objects, since ASCII, HTML, and PDF all have > different requirements. They must take responsibility for > their own encoding. So your code would look like this in the > $formatter->format($table_object) method call: > > $self->_encode($str); > > But $self will refer to the My::Table::HTML object this time, > not My::Table. Of course, the $str variable will have to be > populated by pulling the data out of the My::Table object. > > Essentially, My::Table becomes a container object for the > data, and the formatter objects encapsulate the knowledge of > how to create various document types with the data by > traversing the My::Table data structure. Adding the quirky > loading mechanism that I provided just gives you a > convenience mechanism for choosing which plugin to use. You > could just as easy do this in your code: > > my $formatter = new My::Table::PDF(); > $formatter->format($table_object); > > Is this making any sense yet? :-) > > jpt > _______________________________________________ Perl-Win32-Users mailing list [EMAIL PROTECTED] To unsubscribe: http://listserv.ActiveState.com/mailman/mysubs
