in reply to AUTOLOAD - the good, the bad, and the ugly

It's a nice timesaver to use it to handle simple accessor / mutators without having to write them explicitly

To start with, IMO good OO design is not making an accessor/mutator for all your object fields. I almost never make accessor/mutator functions like you show. Since some values should be read-only (only accessor), and IMO mutators should not mearly be means of setting object fields, but should be tied to the behavior of the object instead.

Perhaps part of my problem is that a lot of my ideas come from Damian Conways 'Object Oriented Perl' (Manning 2000), which is perhaps outdated.

The problem could also be that Damian is insane!!! Personally I love that book, but he sometimes goes over the edge telling you all the insane stuff which can be done, but probably shouldn't. When I had my junior programmers reading that book, I told them specifically to skip most of the middle of the book since it was just full of strange tricks which we would likely never use (of course they were free to read it if they wanted, but I forbade them to use that knowledge without really really really good justification).

Or maybe AUTOLOAD can be used for a lot of neat tricks in little scripts, but becomes quite annoying for large software projects.

My feelings is that AUTOLOAD is a tool for which there are only a few good uses, and those are really fringe cases which will very rarely come up in real world coding scenarios.

For instance the NEXT module would not be possible without AUTOLOAD and IMO that is a excellent usage of it. I recently answered a question about dispatching SUPER calls to mix-ins which used AUTOLOAD (and was very much inspired by the code in NEXT). In Class::Trait::Base I used AUTOLOAD to make sure that calls to SUPER:: were being dispatched correctly, and I think Class::Role && Class::Roles do similar things.

I feel these are justified usages of AUTOLOAD, since there really is no other way to accomplish them without AUTOLOAD. I do not think it is a justified usage of AUTOLOAD to save typing time (auto-created accessors/mutators and delegation), since I think many times that leads to overly clever code which is a pain to maintain and many times impossible to extend (ie - subclass).

However, these are all purely my opinions, and to be taken with a HUGE grain of salt.

-stvn
  • Comment on Re: AUTOLOAD - the good, the bad, and the ugly

Replies are listed 'Best First'.
Re^2: AUTOLOAD - the good, the bad, and the ugly
by dragonchild (Archbishop) on Oct 14, 2004 at 19:25 UTC
    Actually, I think your opinions are well-reasoned. AUTOLOAD is kinda like a number of other Perl features - it's very cool, but serves to provide abilities that comes up 1% of the time. In that 1%, the feature is absolutely critical. However, using the feature outside of that 1% is actually detrimental.

    Another feature I think belongs in this list (and is related to AUTOLOAD) is symbol-table manipulation. It's very cool, but should be avoided in most situations. (Yes, I know that a lot of stuff is done via symbol-table manipulation, but that's using the API.) tie is another feature that, imho, belongs in this category.

    Basically, the question is really "Should I use the published API or muck about in the internals?" 99% of the time, the API is good enough. While having the ability to do what needs done in the other 1%, most programmers aren't disciplined enough to not use it when it's not appropriate.

    I'm not arguing for a Java- or VB-ification of Perl. I'm arguing for some self-discipline among Perlers.

    Being right, does not endow the right to be rude; politeness costs nothing.
    Being unknowing, is not the same as being stupid.
    Expressing a contrary opinion, whether to the individual or the group, is more often a sign of deeper thought than of cantankerous belligerence.
    Do not mistake your goals as the only goals; your opinion as the only opinion; your confidence as correctness. Saying you know better is not the same as explaining you know better.

[reply]
      Another feature I think belongs in this list (and is related to AUTOLOAD) is symbol-table manipulation. It's very cool, but should be avoided in most situations. (Yes, I know that a lot of stuff is done via symbol-table manipulation, but that's using the API.) tie is another feature that, imho, belongs in this category.

      I agree on both of these items as well. And while personally I do like mucking around with the symbol table, I try to do with great respect for the power it gives me and not to abuse it for the sake of just being clever. As for tie, I have only ever used it once, and much like my uses of AUTOLOAD, there was not other way to accomplish the same thing by other means.

      I'm not arguing for a Java- or VB-ification of Perl. I'm arguing for some self-discipline among Perlers.

      I don't take your statements to be that at all, I see your case as one for rational restraint and only going to war,.. ahem I mean symbol tables/AUOTLOAD/tie if you have to.

      -stvn
[reply]
      Should I use the published API or muck about in the internals?

      I've been thinking about this for a couple of days now, to give sanity the chance to overrule my insanity, but it hasn't.

      sub AUTOLOAD{}, $AUTOLOAD and tie are as much APIs as use base;, @ISA and bless.

      Both sets of function employ symbol table manipulation and 'magic'. You're being selective about which set you choose to ordain and which you choose to deprecate.

      I'm not arguing for a Java- or VB-ification of Perl.

      Actually, I think you are.

      I'm arguing for some self-discipline among Perlers.

      This sounds like the same argument as that put forward by those who vote to enforce helmet laws on motorcyclists, even though they have never ridden a motorcycle. The phrase that comes to mind is "The nanny state".

      Examine what is said, not who speaks.
      "Efficiency is intelligent laziness." -David Dunham
      "Think for yourself!" - Abigail
      "Memory, processor, disk in that order on the hardware side. Algorithm, algorithm, algorithm on the code side." - tachyon
[reply]
[d/l]
[select]
        Yes, they are a part of the API, just as much as symbol-tables are ... depending on how you define "API". I'm not talking semantic quibbles here, but a real difference between definitions.

        I'm not choosing to "ordain" or "deprecate" anything. I have a personal line in the sand, and I do understand that the line is my line and only my line. That line is the API line. If I cross it, I am mucking about with the internals.

        Unlike Java or VB, the API line isn't the Berlin Wall, made of concrete and topped with concertina wire. It's a line with lots of gray areas - it's actually more of a "zone" than anything else. It's a zone that, IMHO, one should enter only upon careful consideration of the benefits and drawbacks. It's the zone that, in my experience, separates those who sling Perl code and those who understand Perl programming.

        Now, if you choose to cross that zone, you (hopefully) are conciously desiring to have some of the restraints and limits lifted. It's no coincidence that you usually have to disable at least some portion of strictures to muck about on the other side of the API zone.

        It's also no coincidence that code written on the other side of the zone is almost never self-documentable. This is the code you spend 2-3 hours in a code review explaining how the darn thing works and you end up with a decent lecture on some portion of the Perl internals. I'm talking about the Damian side of the world. You know, the modules he writes, then puts in the documentation under BUGS something like "There almost have to be some bugs in code this funky."

        Not every use of any feature I would mark as being beyond the zone qualifies. But, for every simple usage, one can think of two usages that aren't so simple. That's why it's not a hard-and-fast line; it's a zone.

        As for your last comment ... I was arguing for self-discipline. If you want to go ahead and muck your own application up, that's your own damn fault. I don't have to maintain it, so I couldn't care less. I don't want to be involved in how you do your code.

        What I was arguing for (and which was completely unobvious) was changing how the community through docs and sites like this present these capabilities. We already strongly dissuade people from using symbolic references, a feature I think most of us would consider beyond the API zone. Why should it be any different for AUTOLOAD, symbol-table manipulation, tie, and other, similar features? We can argue about which features and sub-features truly belong in that zone, but I would hope we agree that there are certain areas newbies shouldn't enter, for their own sanity. The Llama book doesn't discuss AUTOLOAD, save in very general terms - that's saved for the Camel. Same with tie, eval, and s///e(e(e)). No-one complains about that ...

        Being right, does not endow the right to be rude; politeness costs nothing.
        Being unknowing, is not the same as being stupid.
        Expressing a contrary opinion, whether to the individual or the group, is more often a sign of deeper thought than of cantankerous belligerence.
        Do not mistake your goals as the only goals; your opinion as the only opinion; your confidence as correctness. Saying you know better is not the same as explaining you know better.

[reply]
Re^2: AUTOLOAD - the good, the bad, and the ugly
by shemp (Deacon) on Oct 14, 2004 at 21:20 UTC
    Don't get me wrong, im only making simple accessor / mutators for those pieces of data that only need them, and not something more complicated. There are plently of other methods that are hand crafted - many complicated accessors / mutators. As my job is mostly data warehouse work, i end up with classes that mess with a lot of data.

    Damian is insane
    I'm beginning to think that myself, as his *interesting* ideas begin to bite me more and more.

[reply]

In Section Meditations