I've usually inherited from the TCollection and TCollectionItem rather than
the TList when doing this kind of thing. They are a much overlooked class
that provide a great deal of flexibility. If they really are not suitable
then I would suggest that you create a wrapper around the TList rather than
inheriting from the TList. There are not that many properties and methods
to duplicate and the implimentation of them is straight forward (and it
also allows much greater flexibility over hiding some properties or methods
that may be dangerous to your class if they were accessible by users of
your class).
Phil.
From: Nahum Wild <[EMAIL PROTECTED]> AT tawa on 19/08/99 09:39 ZE12
To: Multiple recipients of list delphi <[EMAIL PROTECTED]> AT
tawa@kauripo@CCMAIL
cc: (bcc: Phillip Middlemiss/NZ Forest Research Institute/NZ)
Subject: RE: [DUG]: Circular unit references - gotta love'm!
In reply to everyone so far - I considered the 'Define an abstract class'
approach, but it does not acheive what I want as I still have to set its
type when I reference it. My real world example that follows should
clarify the situation a bit :
One functions as a list of the other and is currently a TList, so I end up
doing things like this:
TNeuron(Neuron.LinkedNeuron[i]).Fire;
Other classes also contain a TList of neurons and I end up doing things
like
TNeuron(SomeOtherObject.LinkedNeuron[i]).Fire;
I want to inherit from the TList and create my own default array property
like:
property Neuron[iIndex : integer] : TNeuron read GetNeuron write SetNeuron;
default;
And later add some searching behaviour. This means that I can stop typing
the TObject returned from the TList:
Neuron.LinkedNeuron[i].Fire;
Makes my code easier to read etc... Basiclly I got annoyed with having to
set its type all the time. :-) Yes I could read it into a var and then use
the var, I even do that where possible. But there is a signifigant number
of places where that would clutter up the code more. So I thought I would
get the list to return the right type rather than TObject as TList does.
Nope its not a very reusable concept, but its not designed to be.
Nahum
-----Original Message-----
From: Kerry Sainsbury [mailto:[EMAIL PROTECTED]]
Sent: Thursday, 19 August 1999 09:05
To: Multiple recipients of list delphi
Subject: Re: [DUG]: Circular unit references - gotta love'm!
--- Nahum Wild <[EMAIL PROTECTED]> wrote:
> Does anyone know how to get around the following issue where I have
> two
> different classes that each contain a reference to the other in their >
definition, the problem being that I want them in different units.
> As
> predicted delphi spits a 'circular reference' error at me. :s(
My honest answer would be to suggest that you shouldn't write code like
that :-) You don't want to create such dependencys between your classes --
it makes reuse too tricky.
What's your real-world example? Perhaps we can think of a more elegant
solution to the problem.
===
Cheers,
Kerry S
-- Systems Engineer, Inprise NZ. [EMAIL PROTECTED]
_______________________________________________________________
DO YOU YAHOO!?
Get your free @yahoo.com.au address at http://mail.yahoo.com.au
---------------------------------------------------------------------------
New Zealand Delphi Users group - Delphi List - [EMAIL PROTECTED]
Website: http://www.delphi.org.nz
---------------------------------------------------------------------------
New Zealand Delphi Users group - Delphi List - [EMAIL PROTECTED]
Website: http://www.delphi.org.nz
---------------------------------------------------------------------------
New Zealand Delphi Users group - Delphi List - [EMAIL PROTECTED]
Website: http://www.delphi.org.nz
