On Thu, 28 Sep 2000, David L. Nicol wrote:
> First we create a virtual environment to load the package into, then we
> define the methods we wish to overload, then we define all the methods
> to pass through the args -- No, this is not needed at all, we can use ISA
> for that can't we!
>
>p
On Thu, 28 Sep 2000, David L. Nicol wrote:
[snip]
>sub speak { print "kerokero"; }
>
>foreach (?) { # go through all the methods defined in Frog::Frog
> # I know there is a way to do this but do not know what it is
See RFC 335 (v1): Class Methods Introspecti
> >So anyhow, yes, this is a big, icky problem.
We want to subclass things but have them still retain their old pre-modification
names, w/o changing the thing we are altering (only masking it.)
Right?
Here's an alternate approach:
What if, instead of adding an additional and confusing bag of
>I haven't (and won't) have time to go into this in detail :-(
>
>I feel that this proposal is solving the wrong problem. The issue is
>that the original Forest and Frog (or DBI and DBI::st) classes are not
>*designed* for user-definable Frogs (DBI::st's). If that functionality
>is widely needed,
>The DBI has this very problem! DBI->connect() returns DBI::db
>objects, DBI->prepare() returns DBI::st. If you want to override the
>behavior for statement handles and connections, its not enough to just
>subclass DBI::st and DBI::db, you must also subclass DBI and override
>connect() and prepa
>I wonder if this problem couldn't be solved with a proper combination of
>@ISA, SUPER::, NEXT::, and use delegation? (calling Damian... :-)
The problem I see is a bit of trickery would be necessary to get
static calls to the class to resolve to the appropriate method.
Using Schwern's DBI examp
