As for AUTOLOAD, I still disagree. I agree with you that the interfaces should be consistent and the implementations reasonably so. I agree that a standardized implementation helps with that. But AUTOLOADs at key places can still be of great assistance. For instance suppose you need an improvement in startup time. Why not use AutoLoader? If your usage pattern means that any given user only uses a small subset of your total application, the boost could be substantial.

Is that choice going to be unmaintainable? I don't think so! It shouldn't be scattered everywhere. But think of it as being a templating tool. You have templates all over. Somewhere you have code that processes templates and autogenerates code. Would writing custom autogeneration of code everywhere be a horrible idea? Of course! But is having it used in a key way in a key place in your process invaluable? Of course!

Ditto for AUTOLOAD. Think of it as a way to do lazy run-time templates. Useful. Easily abused, but also powerful when used in a controlled, appropriate manner.

As for your specific question, what I didn't like was seeing the use of functions named by fully qualified package name. If you are doing that everywhere, that is a sign of a problem. If it is limited to things that internally should know each other, that is a different question altogether.

As for exporting, all automatic exports in Perl are done with an import method. The usual semantics you see on CPAN are obtained by inheriting from Exporter. If you want to define your own custom import method, that is easy but I would think twice about having a radically different API. An example is at AbstractClass. (It has an import method that writes an import method into the calling class.) Another approach which might fit better into your system is to have a generic import method (something like Exporter has) but have the list of things you are willing to reexport add the things you imported. That allows for an "inheritance" of a functional interface through classes that will play well with multiple-inheritance though not (ironically enough) with AUTOLOAD.

Fair enough with the "medium-sized" issue. Also, the templates are Perl code, not some data file. Which means I don't have to auto-generate anything. It's already been generated for me. :)

I have been looking at possibly adding Autoloader as well as the package that splits your functions into their own files. (I'm too lazy to look it up, plus I'm eating!) However, the startup time hasn't been an issue in that my users don't really care much. This isn't a real-time application, which is one reason why OO Perl is useable.

We're not fully-qualifying package names anywhere else. (In fact, the reason for my import question is because I didn't want to qualify package names outside of Global::Generic_Object, but found myself needing to because of the default import method.) The reason I'm doing it here is because of the lack of use strict. I'm not using strict in this one package because I want to have the ability to play with references. I should probably add strict vars, but I haven't gotten around to it.

Thanx for the idea regarding over-riding import. I had thought of it, but seeing an example helps a lot.

As for the actual topic at hand ... yes, if you over-use anything, the whole becomes more difficult to maintain. This goes for comments, regexps, avoidance of regexps, etc. And, yes, I agree that AUTOLOAD is very good for rapid prototyping and initial templating. But, I still maintain that AUTOLOAD in production code should be extremely carefully examined before deciding to go ahead with it. And, this is someplace where 3:1 comments:code should be there. Why you're using AUTOLOAD and why another method wouldn't be better definitely needs to be fully explained for the person who's stuck reading your code in 6 months. (Can you tell I was a little annoyed at my predecssor and why?)