[fpc-devel] type discussion

[Danny Milosavljevic]

Hi,

Am Samstag, den 04.06.2005, 08:53 +0200 schrieb Hans-Peter Diettrich:
> Jamie McCracken wrote:
> 
> > > Garbage collection is largely no issue when using the Owner concept in TComponent, using TObjectList, etc.
> > 
> > True and thats why I suggested ref counting Tobjects only so that no
> > manual memory management is required. I tend to make heavy use of TList,
> > Tstringlist and TFilestream objects so I cant do everything with
> > tcomponents alas.

I'd suggest creating tlist, tstringlist, tfilestream-like things with an
optional owner (TComponent-like). I've been programming delphi for
years, and trust me, I know how annoying keeping track of tlist memory
is (and I mean _annoying like *@! hell_ :)). Of course having to cast
around list content is even more annoying. But 'm trying to fix that
now, in fpc.

> 
> What do you mean with "Tobjects"? Isn't TObject the ancestor of all
> classes?
> 
> If you mean a dedicated root class for reference counted objects, you
> can use interface instead of class variables (at least in Delphi, not
> sure about FPC).

TInterfacedObject works in fpc too. works fine. Using it all the time :)

> 
> As was already pointed out, GC doesn't work well without assistance in
> actual code. There's no big difference between setting a reference to
> Nil, and calling the destructor or FreeAndNil, for the same purpose.

Setting a reference to nil works automagically (user doesnt need to do
it).
Only remaining serious problem are reference cycles. And thats a BIG
problem (see old java versions and swing, and you will see... its the
horror).
But it still 'only' means you have to set 'some' references to nil
manually. Which is ugly. Either all or none would be cleaner :)

To offset that danger, I've been trying to get weakref on interfaces to
work, but its actually non-trivial to get that to work cleanly without
using your own tinterfacedobject everywhere (which is a 'cant do'-like
thing when using other people's com objects) ... too bad.
What I mean is:

type
  TXyz = class(TInterfacedObject)
    parent: IWeakref;
    constructor Create(const parent: IInterface);
    procedure someCallbackSoIKnowParentIsGone(whereitwas: Pointer);
  end;

  constructor TXyz.Create(const parent: IInterface);
  begin
    parent := TWeakref.Create(parent);
    parent.OnDestroy.Add(someCallbackSoIKnowParentIsGone);
  end;

ideas ? 

> 
> Auto-destroyed local objects, or local interface references, require
> hidden try-finally blocks; from similar discussions I know that many
> people don't like such invisible magics, for performance and
> oth

It always depends on what you are trying to do. If you are building huge
systems, you wont care about some hidden try-finally blocks you would
have needed at the same places and of the same count regardless. And
choice is good, so as long as you can use the old way, who cares. But
wait, you already can use both ways (reference counted and non-reference
counted). So what's this talk about anyways ? There need to be reference
counted list/map/... units ? I know, working on it :)

cheers,
   Danny

-- 
www.keyserver.net key id A334AEA6

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://lists.freepascal.org/pipermail/fpc-devel/attachments/20050604/7709554a/attachment.sig>