http://www.perlmonks.org?node_id=292000


in reply to Re: The costs of packages
in thread 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.

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

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.

      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.

      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.