Hi, Ben. I began crafting an on-list reply, only to find I had nothing
substantive to add. Then I began writing a private message, only to
discover that perhaps this still makes interesting discussion. Now I'm
thinking we may be on to something here that actually applies directly
to the original post.
I think we're on the same page practically speaking, but not
didactically. That is, given a concrete design problem, we'd come to
similar conclusions; but we're taking opposite approaches.
Kripa was looking for general reasons to avoid eval() or to be careful
when using eval(). So we start talking about code fragments in which
eval() doesn't apply. To my mind, that immediately implies a number in
which it does. Or to put it another way, if I misuse eval(), that's not
eval()'s fault; it's mine. To my mind, that's no reason to avoid the
language feature; rather, that's a reason to understand the language
feature before using it (as one ought any language feature).
To compare, some say we should avoid Perl because it allows us to write
messy, dense code. Yeah, so? It also allows us to design concise,
elegant solutions quickly. /But then,/ the argument goes, /no one else
can understand that code./ Roll-eyes. And by the same token, just
because you can write code that doesn't work using eval() in ways that
would confuse someone who doesn't have the perldocs handy, that's a poor
reason to avoid eval() in general.
> You can place the blame wherever you want to. But with a more
> capable version of eval, you can make the proposed design work.
To my mind, it's not about blame. Rather, it's about designing elegant
software that works. And if eval() doesn't do what we want in a given
situation, we use something that does work.
The greater danger is writing code that works but is fragile. So in that
sense, maybe we can indeed add another item to Kripa's list:
* context confusion
eval() executes in the context in which it's called, not the
context in which the code string is assembled. So if these two are
different, be sure your code is clear about which context the
eval()'ed code sees. Otherwise, one might be misled, thinking the
wrong set of variables are being accessed, and inadvertently
introduce bugs.
Other stuff:
> The problem is that the place where you'd like to centralize the
> code manipulation, calling eval, catching errors etc is in one
> place, and the code that you'd like to manipulate is in another...
I guess I don't understand the design requirements. It sounds
potentially like an interesting design challenge. But I think you'd have
to nail down the requirements a little more.
>> Note that $generator...
> It is not a coroutine.
I finally looked it up. You're right. One of these days my mind will
completely go, and about that time I'll be working on a highly
classified, mission-critical project for the Defense Department and...
-TimK
_______________________________________________
Boston-pm mailing list
[email protected]
http://mail.pm.org/mailman/listinfo/boston-pm
