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

How vehement do you want to get?

Try it out on me. :-)

First of all I would not advocate using AUTOLOAD for everything. But there are cases where it is a useful tool to know about. Use it wisely.

For instance how would you write the equivalent of Re (tilly) 1: Nested Classes without AUTOLOAD? (At least and make it look like Perl's object syntax.)

And yes. There is a performance hit. Which is why people play games like I did at Re (tilly) 1: Reverse Inheritance Irritance and auto-instantiate real methods. You pay the price of the AUTOLOAD once only per method that you use. Incidentally the pattern that I used in that post is a common one to see in a lot of OO languages. Generally done with some version of AUTOLOAD.

So I hope that by practical example you see that there are things that AUTOLOAD is truly useful for. No, it should not replace everything under the sun. But it is a legitimate part of the toolkit.

As for the example that you showed, my main complaint is that you are not using strict. Also I would want to export the functions from Global::Generic_Object using Exporter. Beyond that, I would need to know what your definition of medium sized is. If you mean a few thousand lines, I think you are waaay over-engineering it. If you mean 30,000, well I wonder about over-engineering. In a larger application? Plausible. But I would want to see the object model.

In short, I would worry that is a design meant to support an object model that has grown out of control...

As for whether Perl's OO really is, well it is simplistic, it is a little wordy, performance isn't great, but you can do OO and it works. You can play fun OO games and it works. You can lay something complex out and it works.

But if you want OO nirvana, well Perl supports a lot of styles of programming as "second class citizens", OO among them. Perl is not the greatest language for OO. But it works...

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

Replies are listed 'Best First'.
Re: Re (tilly) 2: Perl and Objects, how do you resolve the two?
by satchboost (Scribe) on Apr 11, 2001 at 19:25 UTC
    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.

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