Userdefined Tk::Derived parent for Widget-Addon

strat has asked for the wisdom of the Perl Monks concerning the following question:

Dear monks

I constructed a little addon to Tk::Entry with Tk::Derived, and it works fine:

package Tk::MyEntryCheck;
# ... some code like strict/warnings/...
use base qw(Tk::Derived Tk::Entry);
Construct Tk::Widget 'MyEntry';
sub Populate { # some code here }
[download]

But now I'd like to have a parameter like -widget => 'LabEntry' (or any other widget based on Tk::Entry) and automatically inherit from Tk::LabEntry (or whatever Entry widget the user specifies). Well, I could perhaps use a package Tk::Widget; and try to play around with eval and require and @ISA and the like. But is there an "official" way to write such user-selectable-parent-widgets?

Best regards,
perl -e "s>>*F>e=>y)\*martinF)stronat)=>print,print v8.8.8.32.11.32"

Comment on Userdefined Tk::Derived parent for Widget-Addon Download Code

Replies are listed 'Best First'.
Re: Userdefined Tk::Derived parent for Widget-Addon by Tanktalus (Canon) on Oct 02, 2005 at 20:28 UTC
You can change your inheritance tree. File::Spec does this. Whether it's a good idea or not is another story. The problem with changing your inheritance tree is that it affects all objects of that type, or that are derived from that type. For File::Spec, being that it can't be recast as a different platform, this seems ok. For you, this may be a show-stopper. How I would do this in C++ would be to create a proxy object, a factory to create them, and then call through the proxy for everything. So your Tk::MyEntryCheck object would contain another object in it through a HASA relationship (rather than the ISA relationship you're trying to do). And then you could just replace that object at runtime with a different object that did different things. The advantage is that you can have multiple Tk::MyEntryCheck objects, each of which have different proxy objects that are unrelated to each other, and it can all work. Another way is to create a new package, set it so it ISA Tk::MyEntryCheck, and put the code in there. In other words, reverse the inheritance tree from what you're trying to do. The problem here is trying to ensure that you can fully swap out one entry-check object with another which sometimes can be more difficult, but, if it can be done, it may be less code than the HASA method above.	[reply]

Replies are listed 'Best First'.

Re: Userdefined Tk::Derived parent for Widget-Addon
by Tanktalus (Canon) on Oct 02, 2005 at 20:28 UTC

You can change your inheritance tree. File::Spec does this. Whether it's a good idea or not is another story.

The problem with changing your inheritance tree is that it affects all objects of that type, or that are derived from that type. For File::Spec, being that it can't be recast as a different platform, this seems ok. For you, this may be a show-stopper.

How I would do this in C++ would be to create a proxy object, a factory to create them, and then call through the proxy for everything. So your Tk::MyEntryCheck object would contain another object in it through a HASA relationship (rather than the ISA relationship you're trying to do). And then you could just replace that object at runtime with a different object that did different things. The advantage is that you can have multiple Tk::MyEntryCheck objects, each of which have different proxy objects that are unrelated to each other, and it can all work.

Another way is to create a new package, set it so it ISA Tk::MyEntryCheck, and put the code in there. In other words, reverse the inheritance tree from what you're trying to do. The problem here is trying to ensure that you can fully swap out one entry-check object with another which sometimes can be more difficult, but, if it can be done, it may be less code than the HASA method above.

[reply]