http://www.perlmonks.org?node_id=265722


in reply to Re: Re^3: Macros, LFSPs and LFMs
in thread Macros, LFSPs and LFMs

The advantage lies in the fact that the passed code is preparsed for you. Remember the traps with things like x*x vs (x)*(x) in the body of a C macro? None of that silliness here.

While that is just nice, the power becomes impressive when you consider that since you can easily examine what the parameter code does without error prone manual parsing. A failed assert($foo == $bar && $baz == $quux); can automatically return an error along the lines of "$foo == $bar succeeded, but $baz == $quux failed". Given limited complexity, the macro could also automatically generate errors like "$foo (value: 21) was expected to be in the range from $bar (value: 8), inclusive, to $baz (value: 16), exclusive" when you assert($bar <= $foo < $baz);. Since the intent of a piece of code is implicit in itself, writing comments violates the principle of once and only once, so a reduction of human written commentary to be manually kept in sync with the code manually is very desirable.

The same principles apply for an ok() macro used in unit testing.

Makeshifts last the longest.

Replies are listed 'Best First'.
Re: Re^5: Macros, LFSPs and LFMs
by demerphq (Chancellor) on Jun 15, 2003 at 14:20 UTC

    I can see your point here. Ive done things like this

    sub assert{ my ($stmt,@args)=@_; my $ok=eval"$stmt" or die "Failed to eval assertion '$stmt':$@"; unless ($ok) { no warnings; my $str=eval qq("$stmt") or die "Failed to eval assertion '$stmt' as a string:$@"; die "Failed assertion '$str'\n"; } }

    which works reasonably well, but obviously isn't as satisfactory as your approach, and could even be a security risk as presently written if it were run on untrustworthy data.

    Anyway, Itll be nice though when the new stuff is out at a production grade. I look forward to it. :-)


    ---
    demerphq

    <Elian> And I do take a kind of perverse pleasure in having an OO assembly language...