On 8/16/05, Tim King <[EMAIL PROTECTED]> wrote: > 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.
There is a divergence, but you're right that it is small... > 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). Of course. > 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. Right. > > 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. And here is where we diverge. You say, "eval() doesn't do what we want" while I'm saying, "if eval() was slightly different, it *could* do what I want". But it doesn't in Perl, so my thoughts end there. > 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. Yup. > 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. An example in Perl of where I could see the use of something like this is that if I'm using DBI directly, there is a lot of repetitive looping code that I keep on writing because I want to process a dataset and use lexical variables in my scope. With an eval like I am describing (or with a good macro system) I would be able to remove some of that repetition. Now before everyone jumps on me and chants Class::DBI, something like Class::DBI does nothing to help me with complex reporting needs. For example the data dump that I just did, the heart of which was about 140 lines of SQL, with multiple subqueries and many uses of CASE. (I needed custom Perl because there was a complex join to a table with over a billion rows, and there was no way that Oracle was going to come up with the right query plan. So I wrote most of it in SQL, and then procedural Perl to force it to use a query plan that would get an answer in a few hours, not a few weeks...) In short, please trust that I know what I'm doing. > >> 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... I'm sorry to tell you that it already did. Most of what you're experiencing are the side-effects of the brain-wipe that they did. I wasn't supposed to tell you that, so don't tell the... ***NO CARRIER*** _______________________________________________ Boston-pm mailing list Boston-pm@mail.pm.org http://mail.pm.org/mailman/listinfo/boston-pm
