Re: delphi problem: with Base as Base.ClassType do
- From: "Maarten Wiltink" <maarten@xxxxxxxxxxxxxxxxxx>
- Date: Tue, 18 Oct 2005 18:21:04 +0200
"Skybuck Flying" <nospam@xxxxxxxxxxx> wrote in message
news:dj2r68$94r$1@xxxxxxxxxxxxxxxxxxxxxxxxxx
[...]
> I have already evaluated interfaces slightly and it's easy to tell
> that when using interfaces (which is totally different than using
> delphi classess) is very risky.
It is.
> It's very easy to create bugs when using interfaces.
> Just some simple examples
>
> 1. Object is never destroyed.
>
> mTest := TTest.Create; // class
>
> mTest is a class not an interface.
>
> Therefore the referencing counting mechanism doesn't kick in and
> the object is never freeed.
You are not using interfaces here, so the usual create-try-use-
finally-free pattern applies.
It is in the help files that using interface references is an
all-or-nothing proposition. There should either be only classtype
references or only interface references to any object.
> 2. Never call .Destroy otherwise exception if a reference does exist
> somewhere:
>
> vInterface := mTest;
>
> mTest.Destroy; <- exception.
This is covered by the same rule. Do not mix classtype and interface
references. When using reference-counted garbage collection, *trust it*.
(In practice, that means _make_ it work like it's supposed to.)
> 3. It's not longer possibly to explicitly destroy objects... How can
> one be sure if all objects are truely destroyed ? What if two classess
> with interfaces sare pointing to each other or something like that,
> then they'll never be destroyed.
True. This is a design issue. It's up to you as the programmer to solve
it. But with Observer/Observed patterns for example, it's very easy to
make exactly this mistake.
> On top of that:
>
> 4. Objects are no longer explicitly destroyed, so the programmer
> loses control of the destroy process, and is confrontated with
> objects suddenly being destroyed, or something like that, so becomes
> a lot less predictable and a lot less insight into what is truely
> going on in the system.
That's a non-argument. You're only hiding things from yourself that
your don't need to know. If things are working correctly, objects will
be deallocated when and only when they are no longer being used. What's
not to like?
> 5. Access/reference problems when a class implements multiple
> interfaces. Each implemented interface needs to be reference via a
> seperate variable ?!? Using class variables because confusing to
> say the least.
I'd say the intricacies of interfaces are confusing to begin with.
It is possible to use interfaces without reference counting. That has
its own problems, but it is somewhat more manageable.
> These are just obvious problems with interfaces and only a very very
> short list I am sure that more problems, issues and confusion will
> arise when using interfaces.
>
> So hopefully you can understand what I would vote for not using
> interfaces =D
For once, I can. But when they are the right tool for a job, don't
complain that the other tools don't do it equally well.
Groetjes,
Maarten Wiltink
.
- References:
- delphi problem: with Base as Base.ClassType do
- From: Skybuck Flying
- Re: delphi problem: with Base as Base.ClassType do
- From: Maarten Wiltink
- Re: delphi problem: with Base as Base.ClassType do
- From: Skybuck Flying
- delphi problem: with Base as Base.ClassType do
- Prev by Date: Re: delphi problem: with Base as Base.ClassType do
- Next by Date: Re: Is it possible to cancel a destruction ?
- Previous by thread: Re: delphi problem: with Base as Base.ClassType do
- Next by thread: Re: delphi problem: with Base as Base.ClassType do
- Index(es):
Relevant Pages
|
