(tye)Re: How do I create a submodule transparent to its parent without modifying the parent?

package MP3::Napster::OpennapMessageCodes;
require MP3::Napster;

push @MP3::Napster::ISA,
    "MP3::Napster::OpennapMessageCodes";
[download]

Simple enough for you? I'm not sure I would highly recommend it, though. (:

- tye (but my friends call me "Tye")

Comment on (tye)Re: How do I create a submodule transparent to its parent without modifying the parent? Download Code

Replies are listed 'Best First'.
Re: (tye)Re: How do I create a submodule transparent to its parent without modifying the parent? by deprecated (Priest) on Jan 30, 2001 at 04:06 UTC
Tye (can I call you "Tye"?), I'm not sure sure I understand what youre doing there, but it seems like a rather rude (from a code-ethics standpoint, not your suggestion) way to do things. Correct me if im wrong: There's an @ISA in MP3::Napster. It says it "is a" @ISA = qw(Exporter MP3::Napster::Base). You're (! highly) recommending that I forcibly convince MP3::Napster that it is actually a module of type MP3::Napster::OpennapMessageCodes ? Let me know if I've got this right. I will be posting my solution probably tomorrow. Chromatic didnt do us all the favor of posting publically, but gave me an excellent suggestion in /msg. (speak up, chromatic! heh!) dep. -- i am not cool enough to have a signature.	[reply]
(tye)Re2: How do I create a submodule transparent to its parent without modifying the parent? by tye (Sage) on Jan 30, 2001 at 04:24 UTC
I never said I recommend it, just that I don't highly recommend it. Yes, it is a rude thing to do. But the request was "I have created a new 20-25 methods to add to the MP3::Napster.pm module", "wihout modifying the parent". Seems like a pretty rude thing to want to do. If one is going to be rude, one might as well be rude in a very simple way than in a complex way. Note that it is "unrude" in that If you don't require the new module(s), then MP3::Napster is completely unaffected. Anything that MP3::Napster already inherits from takes precedence over these new module(s) because I used push and not unshift (and because I force MP3::Napster to be initialized before I do the push). So I'm on the fence as to whether one should ever do what I wrote or what was originally asked for, but I don't understand why you would need to do that. I'd probably create a separate class that inherits from both MP3::Napster and these new modules. - tye (but my friends call me "Tye")	[reply]