Re^3: Altering Package Subs and Running In To Problems

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

Comment on Re^3: Altering Package Subs and Running In To Problems

Replies are listed 'Best First'.
Re^4: Altering Package Subs and Running In To Problems by Bovine (Initiate) on Nov 11, 2004 at 10:08 UTC
(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.	[reply] [d/l]
Re^5: Altering Package Subs and Running In To Problems by Aighearach (Initiate) on Nov 11, 2004 at 11:25 UTC
By "stepping on toes" I only meant it in the technical sense, of overwriting another persons code (instead of subclassing). Alternatives to Exporter would be nice to see. You should take a look at `perldoc base`. Be very, very sure you can't use this existing tool. Well, already I can take component1 and make it a subclass called compoment2, and make a subclass called component3, and each one only needs to overload the stuff it seeks to replace. And only the interface needs to be published, even with proprietary code that is done with plugin interfaces. Why would you need the source, just to implement inheritance? -- Snazzy tagline here	[reply]