>>>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 :).

Dragan,

No I do not need a good virus detector, yes I'm sure there is not virus on my PC. What I meant was ... somebody who is _not_ even self-proclaimed addressable in the French language. Sorry about that.


>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.

... and that should be David F(rankenbach). Sorry about _that_ David.

>>
>>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 effort 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.

As you say ... the event-driven paradigm is not in discussion here, allthough it is my observation that together with persistent data access it gets in the way when designing OO.


>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?

My experience is that it's not so much that you cannot consider tables as objects, that would be nice, but _that_ you could write yourself and it is not too difficult. I've taken that approach for my first framework but I decided against it after all.

No, what bothers me in OO with regard to information systems is that you have to build a separate layer for persistent data, and that this layer cuts right through buziness (or domain) classes. As a consequence a good deal of encapsulation and inheritance goes lost.

Whishing you a good week end.

Marc