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