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
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.