>>When they're written, sans probleme (problème?). It's the sound
>that would be "problèmes", but then ... Anyway, I _am_ impressed. For somebody whoh is even self-proclaimed addressable in the French language :).

Hey, I've never said I knew French, no speak , no write - just read sometimes (this.voice.volume=0). To be honest, once we unpacked a TV with a manual printed in French and Dutch (which I also don't speak), and guess which one helped more...

You should see how this looks here - I see "è" as c-caron in my codepage 1250 (pronounced as tch). and actually typed that character in my keyboard layout - I just remembered it looked very funny once I saw it in the header of the message in French :)

>>new incarnation, almost a new person on the same job, doing it more
>>smoothly, graciously, and OOPy. Where's the edge?
>
>From what I capture from my readings on the UT, most of those who have "seen" oop, seem to think that you either OOP or you don't. David F(rankenheimer) seemed most adament of this.
>
>If that is true I think 2 questions have to be answered: Is OOP the right paradigm for Information Systems, and second, given the shift in paradigm and the unreasonable effor to rewrite and rethink (and retest) every little piece of code, can we (our clientele) afford OOP.

From my point of view, OOP solves many things, and the shortcomings are the multitude of properties you have to take care about, and the need to make your code land on its feet, no matter where it's called from. You don't control the program flow anymore; you write reactions to user's clicks & kicks. But then, it's not the OOP, it's event-driven paradigm. Lots of things which worked in FP, but were essentially written quickn'dirty, won't work anymore simply because the programs/methods don't necessarily execute in the same order. It takes more and more planning, and less coding. The trouble is we use the same computers for planning, so there's no rest for our eyes (unless you go out on the street and see few dozen pairs of reasons for walking around).

Is OOP the right paradigm for Information Systems? That really is the question; it surely makes nice operating systems and GUIs, and graphical apps which operate with real objects (CAD systems, for one), but in the DB world they can help us do (complicate?) the GUI, and forget about the problemès once we write the solutions. But still, OOP DB is only halfway done - we still can't write in this.deleted=.t., right? Our cursor objects don't have methods to seek, go to record, pack, reindex for themselves. Or should we just use the OOP paradigm and start writing them?