Paul
> > 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)
> Maintainability is as important a code quality metric as Performance.
> Focussing too much on either to the detriment of the other is bad for a
> project.
I agree encapsulation is the great bonus with OO languages
> Good use of C++ can offer higher maintainability _without_ costing you
> performance. And in certain control applications, dealing with complexity
is
> a bigger threat (to project success) than response time. I'll take correct
> but a little slow over 'fast and wrong' any day - at least you _know_ what
> the problem is.
exactly!
> 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.
> > [22 pages of further rambling on the dialectic of computer
> > systems control
> > vs flexibility edited out here]
>
> Heh :-)
You dont read enough Monty Python
> > To conclude this is nothing wrong with Delphi (or TCollection) just your
> > expectation of it
>
> Whose expectation? Mine?
> I'm not sure how this bit follows from the former stuff.
The point is that is easy to say that TCollection should expose FList but it
doesn't and there may
be good reason (ei the list state is expected to be unchanged after an event
call etc).
And that as in all forms of engineering software languages are compromises.
TTFN
Neven
---------------------------------------------------------------------------
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"
