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

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.