>Hi Bill,
>
>I swear I'm not dogging you :-)

I love having constructive debates, this is how I learn. I have been keeping quiet because of the flame wars up here, but I decided that I needed to talk, so it just seems that you and I are wanting to talk about the same things *bg*

>The point Erik raised is not the theoretical benefit of constants, and there are many. But it's the squirrelly and hazard-prone way in which VFP supports them that makes them a pain.

Oh, I know, I gathered that you were all aware of them (the theoretical benefits), and I have seen the limtations you are referring to. But, I am in a phase where I am trying some new constructs in my coding style, and #DEFINE's are one of them. So far they haven't flaked out on me--but I am writing small, self-contained components, and that may be within the limitations. I am also starting to reconsider, after reading this thread.

Personally, I think its non-standardness (not just with the pre-processor) that make it harder than it should be for VFP'rs to move to other languages (cross-thread ref) For example, it would be nice to use parameterized macros, but... and java developers can call class methods without specifying an object ('this' seems redundant, even if it is the C++ way)

But, in the past couple of months I have been removing magic numbers and strings from my classes, and I haven't had any problems. And in more than one instance, its made a change that would have been error prone, trivial.

>It's like OOAD principles. I find myself violating them at least once in every application I develop. Why? Because the "true and correct" way sometimes gets in the way of the goal, which is to create a hassle-free, error-less application for my client.

I have been trying to follow principles unless I have a reason not to. Again, I am kind of going through a metamorphasis, and I am trying to get a real handle on my coding structure.

I see "true and correct" as ideals, and I appreciate that the real world isn't ideal, but my take has been until I have a reason not to follow a sensible principle, I should seek the pearl of wisdom in it until I have one. Its kinda like the Normalization debate up here not too long ago. The practice I was siding with was that you fully normalize your data, then when you have a *reason* to denormalize, you do so. In the same vein, Write well-factored code, and *then* start throwing out ideals, for performance, implementation flakes and various other kluges.

Again, since you guys have more experience than I, you have seen many of the pitfalls that I am probably skirting dangerously close to, but I figure I have to in order to get to the next level (JVP's experience vs. theory). So in practice, you simply skip past the ideal phase of implementaion, because you already know the pitfall.

>It's like Codebook (Menachem, Yag -- don't sent hit men after me). Or the Tastrade example. Technically beautiful constructs but applications designed on those "politically correct" frameworks run like shit. IMHO, a client doesn't care how pretty things are under the hood, they want results.

True, but as the refactoring crowd would say, if the code looks ugly its likely to be hard to maintain, or modify. If these aren't an issue, or not a problem (say its only your code for example) than it's a waste to make it look good.

As you said the situation dictates, and the deadline looms. OK I am going to bed, I will pick up this really great conversation (if you are still interested) tomorrow morning.

Later,
Bill