Hi Ed,

Call me a stupid SOB, but I think I have so much mental baggage from my pre-VFP days with FPD,FPW,FPD2.0,FB+,Clipper,dBASE,Quicksilver coding styles that I often develop method or proc code procedurally, and then do an OOP refactor.


>>My point was procedural STYLE coding is no better or worse than OOP STYLE coding. The bottom line is really who is using the tool and how their using it.
>>
>
>I've done both, and find that, at least for myelf and a fair number of the other people I've worked with in design and development, it's easier to factor and understand the client problem space from an OO perspective. Your Mileage May Vary. The first few OOA/OOD experiences I had were painful; 15 years later I would not go back to Structured Design and Analysis tools on a bet. Maybe for a whole lot of money if I didn't have to deliver on time and on target...
>
>>You say that OOP improves maintainability and ease of adaptation, I say that good design and coding techniques are more responsible for improved maintainability and adaptability than the tool chosen to implement the solution. Certainly some tool architectures lend themselves to greater functionality, quicker development cycles, and ease of use but doesn't it all really come down to how you use the tool?
>>
>
>YMMV. It's not just the toolset, it's the problem representation and understanding of responsibilities and collaborations in the underlying things that are represented. I've used several different notations (and several different tools) for OOA/D and SAD - the underlying approach of what you needed to represent mattered more than the way it laid out on paper or the symbols it used.
>
>>Your comments that OO concepts and practices are complex and that may be the reason MS hasn't implemented it in VB and that we all are paying a price for the continued support of Backward Compatibility in VFP. Isn't the backward compatibility in VFP there for exactly this reason ? I always thought it was there so it was easier to "port" old applications and leverage some existing knowledge while you come up to speed on the new technologies. I don't think it forces you to do these things or use old techniques its just there if you want it.
>>
>
>I don't know about you, but I develop new apps from scratch as well as maintain some systems whose roots are back 12 years, and avoid xBASE-ish app coding whereever possible. I'm not locked into a code cycle because I have upmteen million lines of xBASE code that I'm married to, where the design is poorly documented and almost as readable as Linear B. VFP is a great data-centric OOP environment; original xBASE techniques look and feel like the bad old ISAM days from writing COBOL. I've taken positive steps in my own apps to rework and rethink the legacy away from record-oriented processing to set-based processing. As usual, YMMV. If you haven't read it, take a look at "Effective Techniques for Application Development with Visual FoxPro 6.0" by Jim Booth and Steve Sawyer for some non-xBASE-y notions of VFP development.
>
>If I were married to a language, I've far more time in the trenches in assembler and C as a systems programmer than I have in xBASE, going back to itty bitty PDP 8i lab systems better than 25 years ago. And I still remember the damned instruction set for the 8 - lessee - CLA CLL...
>
>>On the "having six dozen ways to do things" may very well complicate the interpreter but as this is a interpreted language and we have no control over the included run-time classes I rather like having the ability to attack a problem several different ways while coming to the same or similar solution. Its that individuality thing.
>>
>
>Consistency in approach leads to better maintainability. If I've consistently done something in one way, the next guy up at bat doesn't have to pick up the other 5 flavors that didn't make the code clearer or cleaner. I'm not the only person who deals with my code. I sometimes have trouble remembering what way I tried to do something the next morning (this seems to follow the very, very long, painful nights most often.) Maybe I'm getting senile. Or maybe I've learned that 'individuality' makes for a maintenance nightmare. I'm boring. And consistent. And I have a good chance of being able to look at a block of code and figure out "Whut duzzit dew" and "Y didit bust". And then fix it in the same old, boring fashion...
>
>Boring works for me - the computer doesn't seem to mind doing the same thing over and over and over - in fact, it likes it!
>
>>You feel that OOP has given you advantages with its implementation and I feel the same way, however its not the end-all or only way to go.
>
>Didn't say it was, I just said it was easier once you got past the OO learning curve point. If you don't have to detach from procedural approaches from the start, it isn't inherently harder to learn OO. I maintain that it's harder to shift from a procedural paradigm to an OO paradigm even with a common base language than to swap in an xBASE-BASIC translator in the brain and use the same procedural approaches to programming you already knew and loved from dBASE/Clipper S'87/Fox/QuickSiilver/whatever. I still believe that much of VB's success is due to the number of people with a little exposure to some flavor of BASIC or xBASE, which is at its roots similar, who didn't need to shift perspectives to get some work out of the tool. Plenty of people who knew some xBASE from the dBASE days shifted to VB, not because it was a stronger language - it just had less learning curve to get some initial gratification from the tools.