At 12:30 -0500 21/01/02, Roy Crisman wrote: >I'm all for resetting the itemDelimiter, too. > >Sure, any time you need to use it, you should set it, but, when >working with organic code, it's possible sometimes to also end up >needing to call a subroutine that may use the itemDelimiter, too. >And if you aren't resetting it, then you really have to set the >itemDelimiter before EVERY line of code that is going to use it.
Exactly! You have to set it every time. And if you start inserting calls to other methods in the middle of a method using a global property such as 'itemDelimiter' then you'll have to make sure, that your code is robust enough to allow for the subroutine to change that global property. You want to have "encapsulated robustness", which means that robustness of one "object" (even if it's not really OOP) is implemented *in* this object, and not outside of it. >I dunno. Friendly code to use would always reset. Sturdy code >would set it before each and every line of code that uses it. > >I tend to write friendly code...so I don't need every mention of >'item' to always be playing with the itemDelimiter before it...some >routines I assume that when I set it at the top of the handler that >it hasn't changed 20 lines later. Exactly the "problem": When you have agreed (in this case with yourself) that you're writing "friendly" code, then you start getting sloppy, in the faint hope that "friendly" will pick up where you left out. And what is it really that we're discussing? Is it a cost-benefit comparison? In that case I'd just like to point out that the "put back" system requires 3 extra lines of code for each use of 'item' whereas the "set before use" system only requires 1. Unless you're not only friendly but also naive enough to trust that everybody else is complying to these rules, which would seem really odd, since the motive behind the "put back" system is to be friendly to the incompetent. >But then again, I've rarely had the chance to interface with >co-worker's code in the past several years. Not even necessary, as you have just proven how even "interfacing" with yourself, will cause problems when you're living by that elusive mantra of "put back". All this illustrates why I do not like the advice of "put back": People will start relying on it as a rule. You start operating like: "Lemme' see, I'm introducing a subCall here, but I don't need to pay attention to the itemDelimiter, because the subCall will reset it politely." Resetting it in itself *is* friendly, and does not in itself introduce any damage, but it's the institutionalization of the rule that causes the damage, because - as I've said before - people will start to misinterpret it, as a justification of *not* setting it before use. And as others agreed to before in this thread, that was *not* the point. Resetting was only meaningful as an addition to "setting it first". But that gets lost in the haze. Jakob [To remove yourself from this list, or to change to digest mode, go to http://www.penworks.com/lingo-l.cgi To post messages to the list, email [EMAIL PROTECTED] (Problems, email [EMAIL PROTECTED]). Lingo-L is for learning and helping with programming Lingo. Thanks!]
