in reply to Re (tilly) 2: Perl and Objects, how do you resolve the two?
in thread Perl and Objects, how do you resolve the two?

Medium-sized is 30,000 lines of actual code and 70,000 lines of script-generated templates. In addition, this model allows for extremely easy extensions of the application. (In fact, for other reasons, it has been rebuilt to allow for this.) The object model is clean-ish, if you're wondering.

The way one uses that module is to inherit it through @ISA. Then, $self->get(-FOO) works quite nicely. $self->exists(-FOO) is included primarily for completeness than a real need for it. You don't Export the functions. (The only function I really want to Export is define_attributes, but I'm having problems getting define_attributes within the scope of grandchildren and further down. Any thoughts?)

I still return to my main objection concerning AUTOLOAD being that it's much less maintainable. I inherited this project and (hopefully!) will be passing it on to someone else in the next 6-8 weeks. If I was passing on an application containing some 250 classes, every single one of them having their own AUTOLOAD, that's a maintenance nightmare! This way, the accessor methods are defined in one, and only one, place. Every object has the exact same API, meaning that learning the system is very easy. (Yes, learning $self->foo() is also easy. I'm whining. But, having the API to within the objects be consistent is still a "Good Thing"(tm).) I hand this off and my successor doesn't have to fight the implementation. That is also a "Good Thing"(tm).

Yes, there are things that AUTOLOAD is good for. I would put forward that a production application isn't one of them.

  • Comment on Re: Re (tilly) 2: Perl and Objects, how do you resolve the two?

Replies are listed 'Best First'.
Re (tilly) 4: Perl and Objects, how do you resolve the two?
by tilly (Archbishop) on Apr 11, 2001 at 20:26 UTC
    And here we see why phrases like "medium-sized" are not very informative. Your concept of "medium-sized" is off by an order of magnitude from what I think is customary in the Perl world.

    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.

[reply]
      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?)

[reply]

In Section Meditations