Beefy Boxes and Bandwidth Generously Provided by pair Networks
We don't bite newbies here... much
 
PerlMonks  

Re: Altering Package Subs and Running In To Problems

by Aighearach (Initiate)
on Nov 11, 2004 at 03:17 UTC ( [id://406895]=note: print w/replies, xml ) Need Help??


in reply to Altering Package Subs and Running In To Problems

The problem is, you are standing there with a bunch of bricks trying to build a grass hut.

Figure out first what you're trying to do, THEN decide how to do it.

Which is to say, your implementation is wrong. You're trying to change the way SomeModule behaves, but you're only the user of that module. Normally this is better changed by subclassing SomeModule. Because then you're not trying to be more than a user of SomeModule. Because, you're only a user.

To do it the way you are wanting to, you'll need a real pragma and not just a regular module. If that doesn't tell you what you have to do differently, you're not ready. Sorry if that sounds dismissive. But, bone up on internals and then you will be in a better place for this.

If the module you're trying to change is arbitrary, then it's harder. But if you're trying to change a SPECIFIC module, then you could also just make sure you've loaded it already in your module, and then as long as your module gets loaded first, use OtherModule will be redundant and ignored and not a problem. But that's very brittle, and not a good idea. THough I'm not sure what you're trying to do in the first place is a Good Idea


--
Snazzy tagline here

Replies are listed 'Best First'.
Re^2: Altering Package Subs and Running In To Problems
by Bovine (Initiate) on Nov 11, 2004 at 07:00 UTC

    Sorry I was unclear about my intentions, though i do have some.
    I updated my post if youd like to read it again.

    I'm trying to make writing extensions easy, and to turn the OO world upsidedown for the fun of it.

    Also would boning up on internals be easy with just the perl manual, and if not would you have any suggestions?

      Unfortunately, internals means picking a good C book, and setting down with the perl source code. There are also lots of good online resources. YMMV

      As far as, turning the OO world on it's head, from what I can tell your system is just really brittle, and steps on everybody's toes.

      What about your system differentiates and improves on subclassing? Can you give a realworld example where your system makes plugins easier than subclassing?

      I use a custom plugin system for my web template system (because Mason lags), I just define a simple interface and then plugins just have to implement a handler(). I thought about making them just run without forcing them to define their own package names, etc, but then it just gets harder to tell which is which when I'm looking at the performance times. That is, doing it the "right" way, I can track stats based on package names. Would your system help me?


      --
      Snazzy tagline here

        (dunno how to quote atm.) Well, I'm not really asking to step on anyone's toes, just for some help. I'm mostly in it for the fun.

        About subclassing:
        I was also thinking of developing something like a DynamicModule module, or looking for one on CPAN (havent done any research yet), which would be an alternate for Exporter. It would allow you to pass arguments to your module (basically simplifying the import confusion with a hash (maybe)).
        This on its own wouldnt do anything profound, but combined with the Plugins, you could have your base module acquire different plugins at runtime. (this, however, clashes with my compile-time desires)
        Also, thought i havent tested it, it seems as if regular Perl inheritance works alongside my Plugin idea (though possibly being really complicated). Though writing different plugins which are all based on an abstract plugin sounds pretty cool.
        Easier is not the idea. Im not trying to change the world here.

        Would my system help.. hmm. Sounds like it could... maybe.
        In a simple case like this (one level of inheritance, only overloading one sub) the 'plugin method' sounds alot like a regular OO one, but perhaps if you wanted to test some code before you fully implement it, you could use a plugin. If your code was open source, plugins could be written at just about any level of your inheritance tree.
        Counting packages could work too, since overloading subs (even though they are "written" into other packages) remember their package.

Log In?
Username:
Password:

What's my password?
Create A New User
Domain Nodelet?
Node Status?
node history
Node Type: note [id://406895]
help
Chatterbox?
and the web crawler heard nothing...

How do I use this?Last hourOther CB clients
Other Users?
Others wandering the Monastery: (8)
As of 2024-03-28 19:24 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    No recent polls found