Re: Re: The costs of packages

Inheritance is not a requirement nor even desirable for my application. The types I am talking about are not really classes per se, just perl convenient wrappers around C-structures that will be passed to OS calls.

On a slightly related question while your around. Is there any reason beyond your personal preference for using create rather than new?

I've tried it both ways and it does exactly what I was achieving with my scheme, but without the overhead, which is great--thanks again--but I'm wondering if you know of some trap waiting for me if I use "new" as the constructor name?

Examine what is said, not who speaks.

"Efficiency is intelligent laziness." -David Dunham
"When I'm working on a problem, I never think about beauty. I think only how to solve the problem. But when I have finished, if the solution is not beautiful, I know it is wrong." -Richard Buckminster Fuller
If I understand your problem, I can solve it! Of course, the same can be said for you.

Comment on Re: Re: The costs of packages Select or Download Code

Replies are listed 'Best First'.
Re: The costs of packages by Abigail-II (Bishop) on Sep 17, 2003 at 00:23 UTC
I was actively avoiding the use of new, because new is commonly used as a constructor. I didn't have the time to figure out what would happen if I placed `new` in UNIVERSAL, while `new` was also being used in an indirect object call (which your real program may, or may not be using). There's nothing special about `new`. And I probably would have used `new` if your example code had used `TypeA -> new` instead of `new TypeA`. Abigail	[reply] [d/l] [select]
Re3: The costs of packages by dragonchild (Archbishop) on Sep 17, 2003 at 13:33 UTC
Inheritance is not a requirement nor even desirable for my application. It may not be for you, but this sounds like a really neat trick to keep in the toolbox, for similar issues. I would think that inheritance would work because the class would be compiled and its @ISA be set. Then, when a method is called, dispatch would take effect, right? ------ We are the carpenters and bricklayers of the Information Age. The idea is a little like C++ templates, except not quite so brain-meltingly complicated. -- TheDamian, Exegesis 6 Please remember that I'm crufty and crochety. All opinions are purely mine and all code is untested, unless otherwise specified.	[reply]
Re: Re3: The costs of packages by BrowserUk (Patriarch) on Sep 17, 2003 at 17:26 UTC
Like Abigail, I haven't really thought the inheritance thing through fully as I haven't the need for it, but what you say makes sense as far as I can tell. Once the package is initially generated it should act just like any other class (assuming you generate the right stuff:). Perhaps the only awkward bit would be managing the process of generating superclasses if the user instantiates an instance of a subclass 2 or 3 levels down in a subclass hierachy? `use Class::AutoFactory; my $rover = new Dog; # Is a subclass of Canine # Is subclass of Mammal # Is a subclass of Animal.` [download] Ensuring that each of the parent classes comes into being in the right order would require a fairly detailed map of the class hierachy and might be a bit complex to program. Doable, but it would require a fair amount of thoughtful design to get it right in a way that is easily extensible and maintainable. Examine what is said, not who speaks. "Efficiency is intelligent laziness." -David Dunham "When I'm working on a problem, I never think about beauty. I think only how to solve the problem. But when I have finished, if the solution is not beautiful, I know it is wrong." -Richard Buckminster Fuller If I understand your problem, I can solve it! Of course, the same can be said for you.	[reply] [d/l]


Your skill will accomplish what the force of many cannot
	PerlMonks