in reply to Re^6: Autoloading tie routines
in thread Autoloading tie routines

For more on the God antipattern see http://en.wikipedia.org/wiki/God_object. It refers to the case when one class or module tries to take on too many jobs at once. This defeats the entire point of modularity, which is to enable code to be broken into modular pieces, each of which has reasonable complexity.

If you do not know what benefits modularity is supposed to bring, or what good modularity looks like, please pick up a book like Code Complete 2. It is a large and important topic, and one I certainly don't have time to go into in any depth today.

Moving on, it sounds like you are micro-optimizing on memory usage. The vast majority of mod_perl sites should just use a reverse proxy in accelerator mode and then not concern themselves overly much with memory needs. See this guide for an overview of what that is, and how to do it. (Yes, it is a 1.0 specific guide. But the advice still applies pretty well to 2.0. BTW I really, really hope you're using pre-fork mode with 2.0...)

That said, I don't know the exact amount of memory needed to have 100 entries in a symbol table, but it is going to be at most a few K. (The functions themselves take up no space because they already exist.) If you are having trouble with running out of memory, this is not where you should look for improvements.

Moving on, the syntax *foo = $coderef; is the standard way to manipulate the package table and install a function. See perlmod for more examples. It is certainly better than the eval solution that you are using in your AUTOLOAD. Better in what way, you ask? Well for a start, if the code you are generating is wrong, then the eval will silently fail and you won't get a good error message. Real example. If one of your constants is supposed to be "Hello, world" then your eval will fail, no error will be reported, and your AUTOLOAD is going to blow up. So compare: 

# This might break badly depending on $value
eval "sub $AUTOLOAD { $val }";

# This will work no matter what $val happens to be.
no strict 'refs';
*$AUTOLOAD = sub { $val };

[download]
Which means that this is a piece of syntax you really should learn.

Finally we come to your two questions. Yes, you can replace $AUTOLOAD with $constname if you are in the right package. Secondly the goto will go to the new function you just defined if it was properly created by eval, and it just returns a value. So you can replace one by the other. However as your code currently stands, that goto is the only sign you are given that your code broke if it broke.

Replies are listed 'Best First'.
Re^8: Autoloading tie routines
by cmac (Monk) on Feb 03, 2009 at 22:33 UTC
    The eval was inherited (in the older meaning of the term) from the predecessor package, which was written in 1998. I've happily changed the second-last code line to *$AUTOLOAD = sub{$val};. In the next statement, I forgot that the object of using a constant name was to get the constant's value, which is why the goto is needed. I may be getting too old for this.

    I was not familiar with "God module/antipattern" terminology. Having been in programming since '63 I value modularity highly, and would never create/architect a module like the one I'm working to replace.

    But having inherited (in the classic sense) a bloated package, and knowing how much compatibility means to many people, at the moment I'm keeping compatibility. Not that the older package probably has many users: the problems I know about probably preclude that.

    On the other hand, having 8 packages inherit from XYZ::ABC may be OK this once, seeing as the only thing "in" each package is a 1;.

    Last question for now: to pursue the compromise course, my instantaneous version of this AUTOLOAD contains:
                    my $subname = lc($mmx) . '_' . lc($sah) . '_' . lc($fu
+nction);
                *$AUTOLOAD = sub {
                    my $base_sah_ref = shift;
                    # dereference the base "sah"
                    unshift @_, $$base_sah_ref;
                    goto &$subname;  # or &{*$subname{CODE}} ??
                };
                goto &$AUTOLOAD;

    [download]
    Is Perl smart enough to capture the current value of $subname in the anonymous sub, rather than use a reference to a local variable that will soon go away? Is this one of those "reference count" things wherein perl is superior to C?

    cmac
    www.animalhead.com
[reply]
[d/l]
[select]
      The goto is not needed, you can just return $val.

      To answer your question about your later code sample, since you are using variables declared with my, Perl will correctly capture the current value in the anonymous subroutine. This is called a closure.

      To address an issue commented on in your code comment, Re: what is the difference between *a and *a{GLOB}? explains why &$subname is the same as &{*$subname{CODE}}.

      Going back to closures, a classic book to learn programming techniques using them is MJD's book Higher Order Perl. Or see Why I like functional programming (long) and Re (tilly) 1 (perl): What Happened...(perils of porting from c) (short) for a couple of examples I wrote that you can puzzle through. I'm a fan of techniques that use closures, but only if I am working with people who understand them. There is a definite learning curve in getting used to them.

      Closures can be used in most languages which support lexical scope and anonymous subroutines. That list includes most current dialects of Lisp (the one in emacs is the major exception), most scripting languages (including Perl, JavaScript, Ruby and Python though Python makes it harder than it should be), and virtually any language that calls itself a functional language. Closures are now making their way into mainstream languages. (They are in C#, and are a likely future addition to Java.)

[reply]

In Section Seekers of Perl Wisdom