I would argue that eval BLOCK and eval STRING are closer than indicated
by Mr. Schwern. In either case, you supply an argument which contains
code, and that code is executed. As a small amount of protection
from this dynamic element, fatal errors within the eval()ed code
are trapped and prevented from causing the entire program to
die. Whether the code is a string or a block doesn't alter the behavior
of eval() other than by changing the point in time at which the
argument code is compiled.
That you can use what is really a side effect of eval's
behavior in conjunction with deliberately-generated fatal errors
to implement a kind of exception system doesn't change
the fact that eval() is doing the same thing in both cases.
Thus, it is good polymorphism.
(I would say that the practice of using eval/die to provide an
exception system is itself at best unclear, though that can be
mitigated by the use of modules like Error.pm; but that doesn't
mean there's a problem with the behavior of eval).
However, I agree that close(variable) is less justifiable.
I know what it means to close a file (even if only because I've
been steeped in the world of computers and their filesystems for
years; the analogy to physically closing a paper folder is loose
at best), but the ideas of "closing" and "variable" don't go
together in my head to form any kind of coherent concept.
If I wanted to make variable read-only, I would expect to do it
by setting the read-only attribute on that variable, which I would
further expect to do the same way I would set any other attribute at
any other time. Orthogonality has its good points, even in Perl;
you just shouldn't be afraid to veer off diagonally when it makes sense.
I don't think close(var) makes sense.
--
Mark J. REED <[EMAIL PROTECTED]>
