in reply to Embedding a mini-language for XML construction into Perl

I liked this meditation. However, there's one thing I didn't like: the eval call in define_vocabulary, which is unneccessarry.

Let me show the way to do the same without eval. 

sub define_vocabulary {
    no strict "refs";
    my($elems, $attrs) = @_;
    for (@$elems) {
        my $name = $_;
        *{$_} = sub(&) { _elem($name, @_) };
    }
    for (@$attrs) {
        my $name = $_;
        *{$_ . "_"} = sub($) { _attr($name, @_) };
    }
}

[download]

Replies are listed 'Best First'.
Re^2: Embedding a mini-language for XML construction into Perl
by tmoertel (Chaplain) on Nov 19, 2005 at 18:27 UTC
    I had considered not using eval, but in this case I could see no practical advantage to the alternatives – and eval was more consistent with my goal of simplicity. For non-trivial uses, however, I agree that eval's costs (e.g., quoting clutter, parsing overhead, and security concerns) almost always outweigh its benefits.

    Still, if you think there is something inherently evil about eval that ought to eliminate it from all consideration, I would be interested in hearing your reasoning.

    Thanks for your comment.

    Cheers,
    Tom

    Tom Moertel : Blog / Talks / CPAN / LectroTest / PXSL / Coffee / Movie Rating Decoder

[reply]
      Still, if you think there is something inherently evil about eval that ought to eliminate it from all consideration, I would be interested in hearing your reasoning.

      Your eval version actually re-compiles the subroutines several times, if you use the symbol table version, this is only done once. While right now it might not seem a big issue, if these subroutines get more complex (input validation or something like that) it might become more of a cost.

      I could also see a usefulness for being able to define a vocabulary inside a package other than the current one. This is, of course, possible with eval version, but using the symbol table version it would be easier to check for accidental overriding of methods.

      I guess my point is that while eval works just fine now, it will likely not scale very well, and since the symbol table approach is not that much more complex, it probably makes sense to use that and leave room to scale.

      -stvn
[reply]

      Lots of people are mis-using eval. They are calling eval more often then would be neccessary, or compiling unsecure code with it. There are too few legitimate applications where eval is really useful, and these mis-uses are very common, so I've grown to dislike eval (eval-string of course, not eval-block).

      Here, the speed problem doesn't apply as the eval is ran only a few times on program startup, so there's nothing principially wrong in using eval in your application.

      However, I still feel that eval is too powerful for such simple things like creating a set of similar functions which can be done without eval. I just imagine eval as a hairy monster that I don't want to allow in my house even when it's well controlled, does the washing-up and does no harm. Also, I wouldn't like that people think such things are only possible with eval, because that could lead to an over-use of eval again.

[reply]

      Here’s an idea: if you use assignment to globs, you can do it with local from within the doc function. That way, you could conjure the element-name functions into existence for the duration of document construction, and have them wink out of being as soon as the document is completed.

      Makeshifts last the longest.

[reply]

In Section Meditations