>>Not as portable, and it doesn't make people change their mindset to an OOP environment - I've seen too much procedural code ported to VFP (I've even been responsible for doing some of it) where rethinking the design to take advantage of the OOP environment woudl result in a better app.
>
>Not as portable as what? Does everything have to be developed with an OOP mindset? If OOP guaranteed great solutions then there would only be OOP languages. Finally, after you rethink your current designs who will be the judge if the end result is a better app? You or your client?
(1) I'm a much better judge of the long-term maintainability and adaptability of the systems I develop for other people; the system needs to meet the client needs now and accomodate change in the future. OO has proved far more easily adaptable with lots fewer "gotchas" for me. YMMV.
(2) No, bad OOP does not engender good solutions, and good procedural code is not inherently evil. OOP encourages habits that improve the maintainability and ease of adaptation of the code. In my cae, I think I can write and design from both perspectives, and the results of OOA/OOD/OOP have met these goals better
for my clients and
their clients better than designs derived from procedural/data flow design approaches.
(3) OOP IS NOT A GUARENTEED PATH TO ENLIGHTENMENT FOR PEOPLE WHO LEARNED TO CODE PROCEDURALLY. It takes a while to rethink systems from an OO perspective. A good percentage of the people who learned to write procedural code never make the transition to OO cleanly. A clue - what's the worst thing about VB from a VFP programmer's perspective? Why hasn't MS pushed OO down to VB, which is where MS seemingly wants people to develop apps? My belief - MS recognizes that until OO clicks, OO is hard. Once it clicks, things get easy very, very quickly. VB (IMO) doesn't move to OO because too many people in the VB community would give up before it clicked...
(4) WE ARE PAYING THE PRICE NOW FOR MAINTAINING BACKWARDS COMPATIBILTIY IN VFP IMO - having 6 dozen ways to do the same thing complicates the interpreter considerably at a minimum, and allows lazy programmers (all programmers should be inherently lazy) not to rethink how things were done in the past.
What is being gained by continuing to support @...SAY...GET in VFP6 - was the support in VFP5 insufficient? Continuing to support all older constructs even when we have new and significantly different language behaviors,and we've provided tools in prior version to port from the old way to the new way of seeing things is adding layers, translations, code and bulk - can you say "Big freaking runtime library?" - and gives both the app developer and the people writing VFP itself more opportunities to miscue in unexpected ways.
My own experience is # of bugs increases as the size of the code base increases - it may be that you only make a fixed number of mistakes for any given app no matter how much code is involved, in my case, more lines means more typos if nothign else. (yes that was intentional).
At some point we'll all benefit if the new version of VFP doesn't have to support things the way we worked back in the bad old days. Less stuff that can interact unexpectedly with the product, and we don't have to keep porting the stupid conversion tools with each version, too...
