Neven wrote:
> > > I thought 'friend' in C++ is required for the overloading of operators
> > > (long time since i did any C++)
>
> > Yes, friend is often _used_ when overloading operators where
> the operator
> is
> > on one class and is adding or assigning in another class and wants to
> reach
> > inside the private 'other class' state to tweak it i.e. clobber a
> reference
> > count.
>
> The point is that friend if 'required' for overloading of operators -
> probably everything else is an abuse
> (some people just can't be trusted with an intent)
The problem is that 'friend' is used (in C++) because there are essentially
two kinds of private. Private to all class users and private to 'other than
classes that are part of this library cluster'.
Myers concept of Class Clusters is really good - Eiffel has this 'prviate'
distinction (from memory - must read Object Oriented Software Construction
2nd Ed again). I want to encapsulate within my overloaded operators certain
semantics that apply to the _cluster of co-operating classes_. And I don't
want to have to make anything protected or public - that's too visible.
Friend lets you do that in C++, putting all the classes in the same unit
allows that in Delphi.
The concept is valid and necessary. Both languages have had to find
solutions to the issue of rich class libraries.
Can it be abused? Yes. Therefore, should be outlaw it? No.
> > Object databases are often implemented as big chunks of
> persistent virtual
> > memory so that VM paging can be using for locality of reference
> optimisation
> > since they have no explicit indication of when things are read.
> >
> > As a result of the VM page design, they often have no explicit
> indication
> of
> > when things should be written (persisted) and even then, they have
> > everything done in 4K page frame chunks which is somewhat
> inefficient for
> > small tuples.
> >
> > If you data model is heterogenous enough to need object models to avoid
> > piles of unmaintainable object-relational mapping code, you can
> avoid all
> > the O<->R mapping gunk but you'll pay for the VM swapping design.
> >
> > TANSTAAFL.
>
> Your mixing implementation with philosophy - the point is that ordered or
> 'structured' data will always be 'physically' quicker to handle.
That's a truism.
A linked list of objects with pointers to child objects in an OO DB is just
as 'structured' as a bunch of tables in a relation DB. And it can do various
forms of joins faster than a relation DB can do.
You pick the paradigm that matches your problem domain and engineer
appropiately.
Your original claim:
> > It is funny but they same problems are facing DB developers - that the >
> OO databases are horribly inefficient
> compared with relational ones (there is something about Heterogenous data
> that makes it difficult to process)
OODBs and RDBs are efficient at different things. I don't think it's valid
to dismiss OODBs out of hand, nor do I think it's valid to dismiss OO
languages such as C++ or Delphi for real-time control.
TTFN,
Paul.
---------------------------------------------------------------------------
New Zealand Delphi Users group - Delphi List - [EMAIL PROTECTED]
Website: http://www.delphi.org.nz
To UnSub, send email to: [EMAIL PROTECTED]
with body of "unsubscribe delphi"
