Re: Is a Query langauge really necessary in an OODB?

topmind wrote:

> >> I know (from other posts/threads) you don't have much use for
 OO, but
> >> an overriding principle of good OO design is: Object shall
 implement
> >> their own behavior. The current crop of tools have it
 backwards.
> >> Rather than the report generator using some method (SQL) to
 reach
> >> inside my object (record),
> >
> >An SQL call is not reaching 'inside your object (record)', it's
 making a call
> >to (usually) the DB engine. This is not anti OOP.
> >
>
> Are you sure you want to open the messy door about what "OO" is
> and is not?

  Well, as long as it's not w/the OOP A**H*** working in the next cubicle   next to me <g>.

  Seriously, I just stopped by this NG to 'lurk'. It didn't seem to   me that this thread was a 'what is OOP' thread. Usually, I don't   post on those. Something must have come over me. It just seemed   to me that the SQL contention was way out of context. Sometimes, classes   are designed/created to CO-OPERATE (use other resources). I'd say SQL is   a fairly commonly used resource these days. Taking offense to SQL script   'invading' your object is just a weird perspective, it seems to me.

> (The definition seems to be a continuum IMO. IOW, it
> is not all-or-nothing. For example, many agree that Smalltalk is
> "more OO" than Java.)

  My primary tool is Delphi. I followed these type threads on BorPrise   servers for several months until I basically heard it all. They come &   go and last for weeks... same subjects as you mention.   Most discussions seem to end up more as self justification than enlightenment.   (IMHO). The Delphi model is perfect fodder for OO purists to pick apart.   Nevertheless, it works VERY well, with few limitations for most mainstream tasks.
  Several Delphi 3rd party OOP DB's are right on the edge and being used productively.

  I'm very much interested in OOP theory and practical ideas, but not the 'my boat
  is bigger than your boat' OO wars.

  Regards,
  JMcKay  

> >JM
> >
> >
> >> my object should create and pass a view of
> >> itself to the report generator (which is responsible for
 layout). Thus
> >> the 'generic' capability is not dependent upon a standard
 method (SQL)
> >> of violating encapsulation.
> >
> >
> >> --
> >> Brian Price
> >>
>
> -tmind-
>
> * Sent from RemarQ http://www.remarq.com The Internet's Discussion Network *
> The fastest and easiest way to search and participate in Usenet - Free!

-----= Posted via Newsfeeds.Com, Uncensored Usenet News =----- http://www.newsfeeds.com - The #1 Newsgroup Service in the World! -----== Over 80,000 Newsgroups - 16 Different Servers! =----- Received on Sun Apr 02 2000 - 00:00:00 CEST