Beefy Boxes and Bandwidth Generously Provided by pair Networks
P is for Practical
 
PerlMonks  

Re: The costs of packages

by Abigail-II (Bishop)
on Sep 16, 2003 at 23:36 UTC ( #291994=note: print w/replies, xml ) Need Help??


in reply to Re2: The costs of packages
in thread The costs of packages

Now, are there maintainability issues here? Why would you put create() in UNIVERSAL instead of exporting it, ala use My::Types qw(create);?

If you export the create sub, it would mean that each time you call create, the create function in My/Types.pm is called, because it's the create function in the current package. With the UNIVERSAL trick, the create function in My/Types.pm is only called once for each class - a second call to create with the same package name as argument is handled by the create package directly. The example program I gave shows this. This is because UNIVERSAL is searched *last*, while the current package is searched *first*, and that's the crucial difference between exporting and using UNIVERSAL.

Also, I would assume that, since you're eval'ing the package, you could have it do inheritance and the like, right?

Uhm, no. As I understood, the problem BrowserUK was having is that his program typically would use a few classes, but those classes would be picked from potentially hundreds. And the memory of those hundreds "skeletons" was a concern. The "eval" trick (which might as well have been a 'require') makes that only packages that are used consume memory. I didn't get the impressions BrowserUKs original approach considered inherited constructors, and I certainly didn't considered it either.

Abigail

Replies are listed 'Best First'.
Re: Re: The costs of packages
by BrowserUk (Pope) on Sep 16, 2003 at 23:59 UTC

    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.

      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

      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.

Log In?
Username:
Password:

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

How do I use this? | Other CB clients
Other Users?
Others surveying the Monastery: (6)
As of 2019-06-18 21:34 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?
    Is there a future for codeless software?



    Results (82 votes). Check out past polls.

    Notices?
    • (Sep 10, 2018 at 22:53 UTC) Welcome new users!