Re: [DUG] Interfaces
No,
There is some other stuff that is confusing me also to do with interface
inheritance - I think I'm going to have to do some reading.
Alister Christie
Computers for People
Ph: 04 471 1849 Fax: 04 471 1266
http://www.salespartner.co.nz
PO Box 13085
Johnsonville
Wellington
Todd Martin wrote:
Hi Alister
Are you implementing IXMLResidentialType via delegation?
Todd.
I'm having some fun with interfaces
I have two interfaces IXMLResidentialType and IAuctionable.
I have a class which implements these two interfaces
TXMLResidentialType = class(TXMLNode, IXMLResidentialType, IAuctionable)
...
I have some code
var
Res : IXMLResidentialType;
Auctionable : IAuctionable;
begin
...
if Res.QueryInterface(IAuctionable, Auctionable) = 0 then
ShowMessage('Auctionable');
What I'm trying to determine is if Res implements IAuctionable - which
it does (through TXMLResidentialType which effective Res is an instance
of), however IXMLResidentialType doesn't seem to realise this. How do I
make this work?
Does this question make any sense?
If I'm not able to do this it's not too much of a problem, but will mean
a bunch of duplicated code.
___
NZ Borland Developers Group - Delphi mailing list
Post: delphi@delphi.org.nz
Admin: http://delphi.org.nz/mailman/listinfo/delphi
Unsubscribe: send an email to [EMAIL PROTECTED] with Subject: unsubscribe
___
NZ Borland Developers Group - Delphi mailing list
Post: delphi@delphi.org.nz
Admin: http://delphi.org.nz/mailman/listinfo/delphi
Unsubscribe: send an email to [EMAIL PROTECTED] with Subject: unsubscribe
Re: [DUG] Interfaces
That is exactly right, but why would you want to, when ISpeakable supports makeNoise() anyway? You can still pass your TPerson object into a method(AObject : INoiseable) without problems. Todd. However if I change my TPerson to the following TPerson = class(TInterfacedObject, ISpeakable, INoiseable) then all is happy. I don't quite understand fully why as yet - I guess you can't get an interface pointer to an object unless it explicitly states that it supports that interface. ___ NZ Borland Developers Group - Delphi mailing list Post: delphi@delphi.org.nz Admin: http://delphi.org.nz/mailman/listinfo/delphi Unsubscribe: send an email to [EMAIL PROTECTED] with Subject: unsubscribe
Re: [DUG] Interfaces
If I have TPerson = class(TInterfacedObject, ISpeakable) Procedure MakeANoise(n : INoiseable); begin n.MakeNoise; end; and var Person : TPerson; begin Person := TPerson.Create; MakeANoise(Person); //Incompatible types: 'INoiseable' and 'TPerson' end; I can't pass a TPerson to an INoiseable, unless I add INoisable to its class definition. Supporting ISpeakable does not make it support INoisable (annoyingly - and I don't yet understand why not). The background to what I'm trying to do is process an xml file (lots of them really). I have generated a bunch of code (about 7k lines, involving over 80 interfaces and as many classes) using the XML databinding wizard (from a DTD), but there is a significant amount of overlap between many of the objects (and interfaces). So I have been trying to clean up the interfaces so that when I process the files I can reduce the amount of duplicate code. It's taking a lot longer that it should as my understanding of interfaces is limited (although I'm slowly getting there). I'd probably be finished by now if I just did a lot of copy paste - but that would be wrong ;-) Anyway - I'll keep persisting. Alister Christie Computers for People Ph: 04 471 1849 Fax: 04 471 1266 http://www.salespartner.co.nz PO Box 13085 Johnsonville Wellington Todd Martin wrote: That is exactly right, but why would you want to, when ISpeakable supports makeNoise() anyway? You can still pass your TPerson object into a method(AObject : INoiseable) without problems. Todd. However if I change my TPerson to the following TPerson = class(TInterfacedObject, ISpeakable, INoiseable) then all is happy. I don't quite understand fully why as yet - I guess you can't get an interface pointer to an object unless it explicitly states that it supports that interface. ___ NZ Borland Developers Group - Delphi mailing list Post: delphi@delphi.org.nz Admin: http://delphi.org.nz/mailman/listinfo/delphi Unsubscribe: send an email to [EMAIL PROTECTED] with Subject: unsubscribe ___ NZ Borland Developers Group - Delphi mailing list Post: delphi@delphi.org.nz Admin: http://delphi.org.nz/mailman/listinfo/delphi Unsubscribe: send an email to [EMAIL PROTECTED] with Subject: unsubscribe
[DUG] Interfaces
I'm having some fun with interfaces
I have two interfaces IXMLResidentialType and IAuctionable.
I have a class which implements these two interfaces
TXMLResidentialType = class(TXMLNode, IXMLResidentialType, IAuctionable)
...
I have some code
var
Res : IXMLResidentialType;
Auctionable : IAuctionable;
begin
...
if Res.QueryInterface(IAuctionable, Auctionable) = 0 then
ShowMessage('Auctionable');
What I'm trying to determine is if Res implements IAuctionable - which
it does (through TXMLResidentialType which effective Res is an instance
of), however IXMLResidentialType doesn't seem to realise this. How do I
make this work?
Does this question make any sense?
If I'm not able to do this it's not too much of a problem, but will mean
a bunch of duplicated code.
--
Alister Christie
Computers for People
Ph: 04 471 1849 Fax: 04 471 1266
http://www.salespartner.co.nz
PO Box 13085
Johnsonville
Wellington
___
NZ Borland Developers Group - Delphi mailing list
Post: delphi@delphi.org.nz
Admin: http://delphi.org.nz/mailman/listinfo/delphi
Unsubscribe: send an email to [EMAIL PROTECTED] with Subject: unsubscribe
Re: [DUG] Interfaces
Should work as is by the looks of it.
Could also try
If supports( res, IAuctionable, Auctionable ) then ...
I would debug/step into the QueryInterface method and then check the
actual classname of the object you are dealing with to see if it is
actually TXMLResidentialType.
You could always also implement IInterface/IUnknown and provide another
version of QueryInterface (which I have done on many an instance).
Interfaces ... lots of fun!
Myles.
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
On Behalf Of Alister Christie
Sent: Thursday, 7 August 2008 2:47 p.m.
To: NZ Borland Developers Group - Delphi List
Subject: [DUG] Interfaces
I'm having some fun with interfaces
I have two interfaces IXMLResidentialType and IAuctionable.
I have a class which implements these two interfaces
TXMLResidentialType = class(TXMLNode, IXMLResidentialType, IAuctionable)
...
I have some code
var
Res : IXMLResidentialType;
Auctionable : IAuctionable;
begin
...
if Res.QueryInterface(IAuctionable, Auctionable) = 0 then
ShowMessage('Auctionable');
What I'm trying to determine is if Res implements IAuctionable - which
it does (through TXMLResidentialType which effective Res is an instance
of), however IXMLResidentialType doesn't seem to realise this. How do I
make this work?
Does this question make any sense?
If I'm not able to do this it's not too much of a problem, but will mean
a bunch of duplicated code.
--
Alister Christie
Computers for People
Ph: 04 471 1849 Fax: 04 471 1266
http://www.salespartner.co.nz
PO Box 13085
Johnsonville
Wellington
___
NZ Borland Developers Group - Delphi mailing list
Post: delphi@delphi.org.nz
Admin: http://delphi.org.nz/mailman/listinfo/delphi
Unsubscribe: send an email to [EMAIL PROTECTED] with Subject:
unsubscribe
Attention:
This communication is confidential and may be legally privileged. If you are
not the intended recipient, please do not use, disclose, copy or distribute it,
other than to return it to us with your confirmation that it has been deleted
from your system.
___
NZ Borland Developers Group - Delphi mailing list
Post: delphi@delphi.org.nz
Admin: http://delphi.org.nz/mailman/listinfo/delphi
Unsubscribe: send an email to [EMAIL PROTECTED] with Subject: unsubscribe
Re: [DUG] Interfaces
You've declared Res as being a IXMLResidentialType and then asking if
IXMLResidentialType implements Iauctionable, which it doesn't.
You need to make res a TXMLResidentialType as below
var
Res : TXMLResidentialType;
Auctionable : IAuctionable;
begin
Res := TXMLResidentialType.Create;
if Res.QueryInterface(IAuctionable, Auctionable) = 0 then
ShowMessage('Auctionable');
That should work
Regards
Richard Bullin
B.E.(Hons) - Mechatronics
Lowman Consulting Ltd
Ph +64 9 535 8647
Cell +64 21 053 6127
Skype Richard.Bullin
Web www.framecad.com
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
On Behalf Of Myles Penlington
Sent: Thursday, 7 August 2008 2:56 p.m.
To: NZ Borland Developers Group - Delphi List
Subject: Re: [DUG] Interfaces
Should work as is by the looks of it.
Could also try
If supports( res, IAuctionable, Auctionable ) then ...
I would debug/step into the QueryInterface method and then check the
actual classname of the object you are dealing with to see if it is
actually TXMLResidentialType.
You could always also implement IInterface/IUnknown and provide another
version of QueryInterface (which I have done on many an instance).
Interfaces ... lots of fun!
Myles.
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
On Behalf Of Alister Christie
Sent: Thursday, 7 August 2008 2:47 p.m.
To: NZ Borland Developers Group - Delphi List
Subject: [DUG] Interfaces
I'm having some fun with interfaces
I have two interfaces IXMLResidentialType and IAuctionable.
I have a class which implements these two interfaces TXMLResidentialType
= class(TXMLNode, IXMLResidentialType, IAuctionable)
...
I have some code
var
Res : IXMLResidentialType;
Auctionable : IAuctionable;
begin
...
if Res.QueryInterface(IAuctionable, Auctionable) = 0 then
ShowMessage('Auctionable');
What I'm trying to determine is if Res implements IAuctionable - which
it does (through TXMLResidentialType which effective Res is an instance
of), however IXMLResidentialType doesn't seem to realise this. How do I
make this work?
Does this question make any sense?
If I'm not able to do this it's not too much of a problem, but will mean
a bunch of duplicated code.
--
Alister Christie
Computers for People
Ph: 04 471 1849 Fax: 04 471 1266
http://www.salespartner.co.nz
PO Box 13085
Johnsonville
Wellington
___
NZ Borland Developers Group - Delphi mailing list
Post: delphi@delphi.org.nz
Admin: http://delphi.org.nz/mailman/listinfo/delphi
Unsubscribe: send an email to [EMAIL PROTECTED] with Subject:
unsubscribe
Attention:
This communication is confidential and may be legally privileged. If
you are not the intended recipient, please do not use, disclose, copy or
distribute it, other than to return it to us with your confirmation that
it has been deleted from your system.
___
NZ Borland Developers Group - Delphi mailing list
Post: delphi@delphi.org.nz
Admin: http://delphi.org.nz/mailman/listinfo/delphi
Unsubscribe: send an email to [EMAIL PROTECTED] with Subject:
unsubscribe
___
NZ Borland Developers Group - Delphi mailing list
Post: delphi@delphi.org.nz
Admin: http://delphi.org.nz/mailman/listinfo/delphi
Unsubscribe: send an email to [EMAIL PROTECTED] with Subject: unsubscribe
Re: [DUG] Interfaces
Hi Alister
Are you implementing IXMLResidentialType via delegation?
Todd.
I'm having some fun with interfaces
I have two interfaces IXMLResidentialType and IAuctionable.
I have a class which implements these two interfaces
TXMLResidentialType = class(TXMLNode, IXMLResidentialType, IAuctionable)
...
I have some code
var
Res : IXMLResidentialType;
Auctionable : IAuctionable;
begin
...
if Res.QueryInterface(IAuctionable, Auctionable) = 0 then
ShowMessage('Auctionable');
What I'm trying to determine is if Res implements IAuctionable - which
it does (through TXMLResidentialType which effective Res is an instance
of), however IXMLResidentialType doesn't seem to realise this. How do I
make this work?
Does this question make any sense?
If I'm not able to do this it's not too much of a problem, but will mean
a bunch of duplicated code.
___
NZ Borland Developers Group - Delphi mailing list
Post: delphi@delphi.org.nz
Admin: http://delphi.org.nz/mailman/listinfo/delphi
Unsubscribe: send an email to [EMAIL PROTECTED] with Subject: unsubscribe
[DUG]: Interfaces without reference counting
Hi. I'm trying to use interfaces in Delphi, but I want to disable
reference counting. So I created a new class (shown below) with a
method to free the object, but when I call ReleaseObject() I get an
access violation after Free.
Anyone got any ideas about how I can free the interfaced object when I
only have a reference to the interface?
Todd
IamUnknown = interface(IUnknown)
['{171F7C01-2C89-11D7-815B-2C9E07C1}']
procedure ReleaseObject;
end;
TamInterfacedObject = class(TObject,IamUnknown)
protected
function QueryInterface(const IID: TGUID; out Obj): HResult;
stdcall;
function _AddRef: Integer; stdcall;
function _Release: Integer; stdcall;
procedure ReleaseObject;
end;
procedure TamInterfacedObject.ReleaseObject;
begin
Free;
end;
function TamInterfacedObject._AddRef: Integer;
begin
//do nothing - ignore reference counting
Result := 0;
end;
function TamInterfacedObject._Release: Integer;
begin
//do nothing - ignore reference counting
Result := 0;
end;
---
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
Web Archive at: http://www.mail-archive.com/delphi%40delphi.org.nz/
Re: [DUG]: Interfaces without reference counting
Thanks. That confirms my own more recent thoughts on this.
Todd.
- Original Message -
From: Dennis Chuah [EMAIL PROTECTED]
To: Multiple recipients of list delphi [EMAIL PROTECTED]
Sent: Wednesday, 29 January 2003 15:41
Subject: Re: [DUG]: Interfaces without reference counting
You get an AV because after the call to ReleaseObject, the interface
reference goes out of scope. Delphi then automatically calls
_Release on
the interface, but because the implementation object is already
freed, you
get an AV.
A better way of doing this is for ReleaseObject to set a flag, and
when
_Release is called, it checks the flag to determine whether to free
the
object. But this too is dangerous because there may be other
references to
the interface and when they go out of scope, _Release will be
called.
Why do you want to bypass the reference counting anyway?
Dennis.
- Original Message -
From: Todd Martin [EMAIL PROTECTED]
To: Multiple recipients of list delphi [EMAIL PROTECTED]
Sent: Wednesday, January 29, 2003 11:11 AM
Subject: [DUG]: Interfaces without reference counting
Hi. I'm trying to use interfaces in Delphi, but I want to disable
reference counting. So I created a new class (shown below) with a
method to free the object, but when I call ReleaseObject() I get
an
access violation after Free.
Anyone got any ideas about how I can free the interfaced object
when I
only have a reference to the interface?
Todd
IamUnknown = interface(IUnknown)
['{171F7C01-2C89-11D7-815B-2C9E07C1}']
procedure ReleaseObject;
end;
TamInterfacedObject = class(TObject,IamUnknown)
protected
function QueryInterface(const IID: TGUID; out Obj): HResult;
stdcall;
function _AddRef: Integer; stdcall;
function _Release: Integer; stdcall;
procedure ReleaseObject;
end;
procedure TamInterfacedObject.ReleaseObject;
begin
Free;
end;
function TamInterfacedObject._AddRef: Integer;
begin
//do nothing - ignore reference counting
Result := 0;
end;
function TamInterfacedObject._Release: Integer;
begin
//do nothing - ignore reference counting
Result := 0;
end;
--
-
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
Web Archive at:
http://www.mail-archive.com/delphi%40delphi.org.nz/
---
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
Web Archive at: http://www.mail-archive.com/delphi%40delphi.org.nz/
---
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
Web Archive at: http://www.mail-archive.com/delphi%40delphi.org.nz/
[DUG]: interfaces...
'lo - question on interfaces and reference counting/freeing. I'm creatng an interface in Kylix, thats not descended from TInterfacedObject, so I'm adding _Addref _Release and QueryInterface myself (I'm descending from TPersistent), in _Addref and _Release I'm simply returning 1, which I've seen mentioned I should do elsewhere on the net, but I was wondering what I do in the case of freeing my classes, or is the reference counting working already? I note if I try and .Free the instance of my interface, I get an exception... -- \m/ -- ...if I seem super human I have been misunderstood. (c) Dream Theater [EMAIL PROTECTED] - ICQ: 1934853 JID: [EMAIL PROTECTED] --- 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 Web Archive at: http://www.mail-archive.com/delphi%40delphi.org.nz/
Re: [DUG]: Interfaces (and classes that support them)
Factory methods is the way to go. Personally, I prefer to use factory classes (actually factory interfaces). You certainly don't want to limit your design to inherit all implementation classes from the same base class, though, sometimes, it can be helpful to have an abstract base class that implements some of the common methods of the interface. As for your form, you can use an adapter class that inherits from TInterfacedObject. Take a look at TStreamAdapter for an example. Dennis. - Original Message - From: Trevor Jones [EMAIL PROTECTED] To: Multiple recipients of list delphi [EMAIL PROTECTED] Sent: Thursday, August 08, 2002 1:11 PM Subject: Re: [DUG]: Interfaces (and classes that support them) Phil, Thanks for the idea, but it kinda breaks the idea of an Interface being supported by *ANY* class type. In some cases the objects that support the interfaces I'm using are subclassed from TInterfacedObject, other times they may be components or even forms. As luck would have it, a TForm does not subclass TInterfacedObject, so this stops me using this approach. For the moment, I've opted to register factory functions rather than the classes themselves and this seems to cover most issues. Trevor - Original Message - From: Phil Middlemiss [EMAIL PROTECTED] To: Multiple recipients of list delphi [EMAIL PROTECTED] Sent: Thursday, August 08, 2002 8:34 AM Subject: Re: [DUG]: Interfaces (and classes that support them) Trevor, I usually create a simple base class with a virtual constructor that I then descend from where appropriate. eg. TMyObject = class(TInterfacedObject) public constructor Create; virtual; end; TMyObjectClass = class of TMyObject; Now everything that needs to can descend from TMyObject, and the MyInterfaceClass function uses the variables AClass: TMyObjectClass; AObject: TMyObject; This assumes, of course, that you have control over which classes are used. Kind regards, Phil. - Original Message - From: Trevor Jones [EMAIL PROTECTED] To: Multiple recipients of list delphi [EMAIL PROTECTED] Sent: Wednesday, August 07, 2002 5:03 PM Subject: [DUG]: Interfaces (and classes that support them) Hi all, One of the things that I like about using Interfaces is that the classes supporting them can be of any type - Yeeha! However it can be tricky deciding how to construct an object from just a class reference that supports an interface because the TObject constructor is not virtual. My solutions so far amount to stuff like this (where the last registered class is the one to be created): var List : TList; procedure RegisterMyInterfacedClass(aClass : TClass); begin if supports(aClass,IMyInterface) then List.Add(aClass); end; procedure UnRegisterMyInterfacedClass(aClass : TClass); var i : integer; begin i := List.IndexOf(aClass); if i = 0 then List.Delete(i); end; function MyInterfacedClass : IMyInterface; var aClass : TClass; aObject : TObject; begin result := nil; if List.Count 0 then begin aClass := List[List.count-1]; if aClass.inheritsFrom(TComponent) then aObject := TComponentClass(aClass).create(application) else aObject := TClass.create; // Supports should always be true here, its just an easy way to get the interface if not Supports(aObject, IMyInterface,result) then aObject.free; end; end; All of this nonsense seems to work very well at the moment, but I'm unsure how safe it is. The gotchas seem to be: If the class inherits only from TInterfacedObject, its specific constructor is not called, the class must override AfterConstruction to create any needed bits (like stringlists etc.). If the class uses some fancy constructor that requires something other than an owner, then I'm stuck. Does anyone have a more elegant way of going about this that they are willing to share? Trevor -- - 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 Web Archive at: http://www.mail-archive.com/delphi%40delphi.org.nz/ -- - 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 Web Archive at: http://www.mail-archive.com/delphi%40delphi.org.nz
RE: [DUG]: Interfaces
Interfaces will be a big part of future Delphi (Kylix, JBuilder(?))
releases, so there may be some merit in getting to grips with them now?
In D6 you will see interface properties appearing in the object inspector at
design time and so forth (a use outside of designing a nice flat hierarchy)
which will allow you to reference a group of classes by a common interface.
i.e. Find all of the data aware controls on a form...
type
IDataAware = interface
['{293D20D0-0876-4B5A-8FDA-EC32E56042E9}']
procedure DoSomethingThatIsAware;
end;
...
var
intf: IMyDataAware
...
for i := 0 to ControlCount - 1 do
// No need to use the RTTI to check for a DataSource/DataField property
if Supports(Controls[i], IDataAware, intf) then
begin
Controls[i].ReadOnly := True; // or what ever!
or ...
inft.DoSomethingThatIsAware;
end;
I'm not sure if this functionality in D6, maybe someone could clarify, but
in theory you should be able to drop a TEdit on a form, right click on it,
select from the context menu an option that allows you to pick from a list
of available interfaces which interface(s) you would like to implement in
the TEdit i.e. IDataAware, IFormatTextAsCurrency, IChangeColourOnFocus etc..
You could then implement the same set of interfaces on a TGrid, TMemo,
TImage and so forth. (I suppose they would then appear in the Object
inspector?).
Cheers,
Andrew
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On
Behalf Of Sandeep
Sent: Wednesday, 13 June 2001 10:27 a.m.
To: Multiple recipients of list delphi
Subject: [DUG]: Interfaces
Is there any advantage of using interfaces?
Sandeep
Software Developer
CFL
[EMAIL PROTECTED]
http://www.cfl.co.nz
---
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
---
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
RE: [DUG]: Interfaces
Hi Andrew et al, At 21:11 15/06/01 , you wrote: I'm not sure if this functionality in D6, maybe someone could clarify, but in theory you should be able to drop a TEdit on a form, right click on it, Danny Thorpe goes into some detail about new interface features in D6: http://community.borland.com/article/0,1410,27304,00.html From what Danny says, it sounds like published interface properties on components will work like published events in the Object Inspector, viz: Select an interface property and you get a drop down list of components on the form which can bind to that property, ie they implement the required interface. Very cool! He also talks a bit about IInterface (hmmm ...personally I would have preferred TType), which is the new ancestor interface for IUnknown which Max posted about the other day. Paul. - Paul Spain, Excellent Programming Company mailto:[EMAIL PROTECTED] - --- 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
Re: [DUG]: Interfaces
Interesting conversation. I am replying to Nahum's post because that's how it is for me too. One function of interfaces for us is as a specification of a service one element of our application is responsible for providing to another. We can agree on the interface definition without constraining in any way the manner in which the interface is supported. This is not the case if you're using classes to express interfaces. The other thing that occurs is how nice it is to be able to provide things like iterators via simple functions. eg function GetIterator: IIterator instead of procedure GetIterator( out Iterator: TIterator ). Auto gargage collection doesn't seem to me to summarize the significance of this. You've removed the whole try finally nonsense responsibility from the client. The client wants something, he just asks for it. Simple. It's possible that interfaces kill the try-finally construct stone dead. We use interfaces to restore properties like cursors, and there's no reason why you should't use the same trick to call Printer.EndDoc etc.. However, I am in heated agreement with the proviso about mixing interfaces and classes. And if you find yourself calling addref and release yourself you'd better know what you're doing - you can definitely create major messes, especially at close down of your app. Interfaces rock! Cheers, Don Macrae Nahum Wild wrote: You can get around the auto garbage collection easily enough. Neven's simple answer is a good one. They have a huge impact on how you design apps etc... - for the better. Yes I use interfaces. Learning about them was a oh, why didn't I learn about these ages ago type experience, a bit like going from procedural to object oriented. :) Nahum. -Original Message- From: Sandeep [mailto:[EMAIL PROTECTED]] Sent: Wednesday, June 13, 2001 11:57 AM To: Multiple recipients of list delphi Subject: Re: [DUG]: Interfaces On 13 Jun 2001, at 10:46, Neven MacEwan wrote: Sandeep Simple Answer - HUGE I haven't used them yet. And if it is used for automatic garbage cleaning (I think I'm right here) then it may not be a good programming practice, or it may be a lazy way of programming. Sandeep Software Developer CFL [EMAIL PROTECTED] http://www.cfl.co.nz -- - 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 --- 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 -- -- Don Macrae, Excellent Programming Company mailto:[EMAIL PROTECTED] -- --- 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
Re: [DUG]: Interfaces
Peter, I'm not sure what your question refers to, but if it's my suggestion that try-finally is dead then it concerns a neat little trick I got from a presentation by Malcolm Groves at the last Borcon - his IRestore interface. You can get the details from Malcolm's web site at http://www.madrigal.com.au/papers/solidcode/page3.htm Happy to comment further if that doesn't address your issue. Don Macrae Peter Hyde wrote: Don wrote: Auto gargage collection doesn't seem to me to summarize the significance of this. You've removed the whole try finally nonsense responsibility from the client. The client wants something, he just asks for it. Simple. It's possible that interfaces kill the try-finally construct stone dead. I'm following the whole interfaces discussion with great interest (we don't use 'em), but the above leaves me confused. Could you spell out/example the above a little more please if you have time? cheers, peter Peter Hyde, WebCentre Ltd SPIS Ltd, Christchurch, New Zealand * Web automation for online periodicals: http://TurboPress.com * TurboNote+: http://TurboPress.com/tbnote.htm -- handy onscreen notes and instant messaging --- 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 -- -- Don Macrae, Excellent Programming Company mailto:[EMAIL PROTECTED] -- --- 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
Re: [DUG]: Interfaces
At 17:02 13/06/01 , you wrote: function GetIterator: IIterator Auto gargage collection doesn't seem to me to summarize the significance of this. You've I don't think you can overstate the significance of garbage collection or more generally, resource management. Its straightforward to clean up after yourself where the lifetime and usage of a resource is limited to the scope of a function or an object. But consider a public function: function GetIterator: TIterator Who is responsible for destroying the returned object, the producer or the consumer? Its not obvious. The answer is only found through asking, or associated documentation, or reading the source (where available). And that assumes that all users will go to the trouble of finding out, which is drawing a longish bow. Assume further that we've established who is responsible for lifetime and everybody plays by the rules. Great. Now, it turns out that the producer and the consumer are in different threads, and resources are released upon thread termination. What happens when the threads die in the wrong order? AV-a-gogo. So now we also need to enforce thread finishing order. By changing to: function GetIterator: IIterator which returns an interface, all these issues disappear, 9 times out of 10. The iterator gets cleaned up when the last reference is released - end of story. The remaining 1 time I attribute to poor design, which will _always_ prevail over the best defences! Paul. -- Paul Spain, Excellent Programming Company mailto:[EMAIL PROTECTED] -- --- 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
[DUG]: Interfaces
Is there any advantage of using interfaces? Sandeep Software Developer CFL [EMAIL PROTECTED] http://www.cfl.co.nz --- 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
Re: [DUG]: Interfaces
Sandeep Simple Answer - HUGE Neven - Original Message - From: Sandeep [EMAIL PROTECTED] To: Multiple recipients of list delphi [EMAIL PROTECTED] Sent: Wednesday, 13 June 2001 10:27 Subject: [DUG]: Interfaces Is there any advantage of using interfaces? Sandeep Software Developer CFL [EMAIL PROTECTED] http://www.cfl.co.nz -- - 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 --- 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
Re: [DUG]: Interfaces
On 13 Jun 2001, at 10:46, Neven MacEwan wrote: Sandeep Simple Answer - HUGE I haven't used them yet. And if it is used for automatic garbage cleaning (I think I'm right here) then it may not be a good programming practice, or it may be a lazy way of programming. Sandeep Software Developer CFL [EMAIL PROTECTED] http://www.cfl.co.nz --- 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
Re: [DUG]: Interfaces
On 13 Jun 2001, at 10:46, Neven MacEwan wrote: Sandeep Simple Answer - HUGE Only one reply so far, so should I assume that there are not many people using Interfaces. Sandeep Software Developer CFL [EMAIL PROTECTED] http://www.cfl.co.nz --- 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
RE: [DUG]: Interfaces
You can get around the auto garbage collection easily enough. Neven's simple answer is a good one. They have a huge impact on how you design apps etc... - for the better. Yes I use interfaces. Learning about them was a oh, why didn't I learn about these ages ago type experience, a bit like going from procedural to object oriented. :) Nahum. -Original Message- From: Sandeep [mailto:[EMAIL PROTECTED]] Sent: Wednesday, June 13, 2001 11:57 AM To: Multiple recipients of list delphi Subject: Re: [DUG]: Interfaces On 13 Jun 2001, at 10:46, Neven MacEwan wrote: Sandeep Simple Answer - HUGE I haven't used them yet. And if it is used for automatic garbage cleaning (I think I'm right here) then it may not be a good programming practice, or it may be a lazy way of programming. Sandeep Software Developer CFL [EMAIL PROTECTED] http://www.cfl.co.nz -- - 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 --- 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
Re[2]: [DUG]: Interfaces
They are an extra layer of complexity (IMHO) a lot of extra complexity. Regards Paul McKenzie = Paul McKenzie Jetbet II Developer = [EMAIL PROTECTED] Ph: (04) 576-6822 T.A.B. National Office 106-110 Jackson Street Petone New Zealand Reply Separator Subject: Re: [DUG]: Interfaces Author: [EMAIL PROTECTED] Date: 13/06/2001 11:58 On 13 Jun 2001, at 10:46, Neven MacEwan wrote: Sandeep Simple Answer - HUGE Only one reply so far, so should I assume that there are not many people using Interfaces. Sandeep Software Developer CFL [EMAIL PROTECTED] http://www.cfl.co.nz --- 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(See attached file: att1.eml) att1.eml
Re: RE: [DUG]: Interfaces
Nahum Wild [EMAIL PROTECTED] wrote on 13/06/2001 11:53:45: You can get around the auto garbage collection easily enough. Neven's simple answer is a good one. They have a huge impact on how you design apps etc... - for the better. Yes I use interfaces. Learning about them was a oh, why didn't I learn about these ages ago type experience, a bit like going from procedural to object oriented. :) Ok, give a poor C++ programmer a hint... what are we talking about here? G Specifically, I've seen many definitions for 'interfaces', but none of them seems to quite fit the discussion. Does some kind soul out there feel like enlightening me? -- Corey Murtagh The Electric Monk Quidquid latine dictum sit, altum viditur! --- 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
Re: [DUG]: Interfaces
I design with them now - much easier, from my POV. They are used extensivly in Java as well, so its good practice if you are ever going to move. Nic. On 13 Jun 2001, at 10:46, Neven MacEwan wrote: Sandeep Simple Answer - HUGE Only one reply so far, so should I assume that there are not many people using Interfaces. Sandeep Software Developer CFL [EMAIL PROTECTED] http://www.cfl.co.nz -- - 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 -- Better living thru chemistry AbCdEfGhijLmNopqrstuvwxyz --- 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
RE: [DUG]: Interfaces
Sandeep commented: Only one reply so far, so should I assume that there are not many people using Interfaces. Interfaces are useful for a variety of things. In object oriented programming terms that are used to implement the concept of generisity, and this complements polymorphism and inheritance as the third technique used to design object based systems. In more concrete Delphi terms interfaces provide a mechanism of doing multiple inheritance, they provide a native method of talking to COM objects, they provide a mechianism to produce better 'black box' objects, and they can provide a referenced counting mechanism for memory manegement. So what more can I say past the mention that I use them a lot? Cheers, Max. --- 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
Re: RE: [DUG]: Interfaces
Ok, give a poor C++ programmer a hint... what are we talking about here? G I think you lot call them pure virtual classes - ie a class with no implementation. In Delphi, you can inherit from more than one of them, which is a big advantage. Specifically, I've seen many definitions for 'interfaces', but none of them seems to quite fit the discussion. Does some kind soul out there feel like enlightening me? :) N --- 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
Re: [DUG]: Interfaces
Sandeep Firstly separate the concept of Interfaces from the COM et al implementation (that uses interfaces) and does reference counting etc (ie your comments re garbage collection) Interfaces address the major limitation of the single inheritance model, ie polymorhism. The are simply a structured method is refencing an object in various ways ie. TMyClass = Class(TClass, IMyInterface1, IMyInterface2..) means you can reference an instance of TMyClass as any of 1/ An instance of TMyClass (or its SuperClasses) 2/ An instance of IMyInterface1 3/ An instance of IMyInterface2... If you look at how Delphi implements an InplaceEdit or a Collection it gives you an idea of the limitations of single inheritance. in the case of an InplaceEdit, it may have a lot in common with an existing TEdit but you can't inherit from it (we could do a discussion on 'Wrappper Design Pattens' here...). I was disappointed that the CLX didn't take to oppourtunity to clean this up and define an IInplaceEdit (Delphi because of history seems to be ho hum on interfaces in the Component Lib). Similary for collections the collection inherits from TCollection and the Item from TCollectionItem (again an ICollectionItem would make this easy for example to have a collection of existing classes (and mixed class objects!) Get the idea, if you want to give some commonality to a set of classes, define an interface HTH Neven - Original Message - From: Sandeep [EMAIL PROTECTED] To: Multiple recipients of list delphi [EMAIL PROTECTED] Sent: Wednesday, 13 June 2001 11:56 Subject: Re: [DUG]: Interfaces On 13 Jun 2001, at 10:46, Neven MacEwan wrote: Sandeep Simple Answer - HUGE I haven't used them yet. And if it is used for automatic garbage cleaning (I think I'm right here) then it may not be a good programming practice, or it may be a lazy way of programming. Sandeep Software Developer CFL [EMAIL PROTECTED] http://www.cfl.co.nz -- - 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 --- 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
Re: [DUG]: Interfaces
Nic I design with them now - much easier, from my POV. They are used extensivly in Java as well, so its good practice if you are ever going to move. Also good practive if your not, A lot of the OO Technology is centred around the concept of interfaces (since I think multiple inheritance has a number of implementation and design problems). So being a delphi programmer using interfaces makes the concepts available (thou most of it is 'expressed' in Java) 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
Re: RE: [DUG]: Interfaces
Ok, give a poor C++ programmer a hint... what are we talking about here? G interfaces are another way representing what multiple inheritance (I think poorly) attempts to represent in C++ Specifically, I've seen many definitions for 'interfaces', but none of them seems to quite fit the discussion. Does some kind soul out there feel like enlightening me? The idea is that OOP is supposed to let you model real world objects. And you want to be able to treat similar objects by identifying features that unify them (some properties and methods) and then have your algorithms manipulate them indifferent to further distinctions they may have.(Like operating on TControls indifferent to specifics about each). In C++ if object A is a Widget then it will have TWidget as a base class. So you can treat A as if it were a Widget and be indifferent to further details about it.And if you restrict to single-inheritance derivations ALL of the possible ways of looking at A need to be represented as some base class in it's derivation hierarchy. The problem with this is that real world objects don't come in nice neat hierarchies - and objects can sometimes be more than one thing. In C++ if you are faced with adding a whole collection of new features into an existing class hierarchy you either have to add it to some deep base (a nightmare) or use multiple inheritance (a worse nightmare). Interfaces get around all this by just admitting the reality that the world is not arranged in hierarchies. If something is like a container then it just is. To model this with interfaces you expose the TContainer functionality (some properties and methods) and voila you're a container. If you suddenly have a container that's also a clock - then you also expose a TClock interface and then voila you're a clock too. Interfaces are kind of like pure virtual abstract base classes in C++. But if you've ever tried to actually use multiple bases in C++ on a nontrivial set of classes you know that there are subtle problems with constructor ordering and other wierdness.Interfaces don't suffer from any of this stuff. I think using interfaces is a deep design decision - and usually worth doing. -ns --- 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
RE: RE: [DUG]: Interfaces
Any disadvantages using Interfaces??? Any slower performance??? Anything to look out for??? Regards Colin ## Attention: The information in this email and in any attachments is confidential. If you are not the intended recipient then please do not distribute, copy or use this information. Please notify us immediately by return email and then delete the message from your computer. Any views or opinions presented are solely those of the author. ## --- 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
Re: RE: [DUG]: Interfaces
How do interfaces help i n multiple inheritence? If I have a ClassA and ClassB then if I want to inherit ClassC from ClassA its simple. But if I want to inherit from ClassA and ClassB then using interface I have to implement all the functions in ClassB again in ClassC, so how does it makes life simple? Sandeep Software Developer CFL [EMAIL PROTECTED] http://www.cfl.co.nz --- 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
RE: RE: [DUG]: Interfaces
Sandeep asks: How do interfaces help i n multiple inheritence? If I have a ClassA and ClassB then if I want to inherit ClassC from ClassA its simple. But if I want to inherit from ClassA and ClassB then using interface I have to implement all the functions in ClassB again in ClassC, so how does it makes life simple? The main use for multiple inheritance is defining an object that has the nature of two other classes. And the intention is not to aggregate functionality so much as to have a new object that is can be treated as either of the two bases classes. When you express things this way you see that the use of the base classes in this case is highly misleading, as you are not defining functionality so much as the interface by which you want to talk to an object. The base classes exist simply to provide virtual abstract methods that descendants will have in common. So instead of using artificial base classes to define common interfaces, you explicitly define the interface(s) that you to have available, and leave it up to the objects to implement the interface(s) if they need to. Then objects of several different hierarchies can all be treated transparently in a certain context. The above does not imply that you can use inheritance to provide base objects classes that all implement a certain interface, not does it prevent the interfaces being delegated by objects to other objects that they aggregate. So one method of avoiding the problems that you mention above is to have both ClassB and ClassC use an instantiation of a separate object ClassD to implement a certain behaviour, and bother provide an interface that delegates the interface down to that class. Then you have both code sharing, inheritance and interfaces all working together to provide the actual object functionality you want to express. Cheers, Max. --- 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
RE: RE: [DUG]: Interfaces
Colin Fraser asked: Any disadvantages using Interfaces??? Not really. The main issue is designing your classes so that you can actually take advantage of interfaces, rather than deep inheritance. Any slower performance??? No. Delphi interfaces are actually implemented as pointers to a part of the VMT of an actual object. The dispatching of an interface call is no slower than dispatching a virtual methods, and faster than dispatching a dynamic method. The only overhead you get is in extra calls to _AddRef and _Release that Delphi does to handle the interfaces lifetimes. But that's only a matter of a few tens of CPU cycles in the era of 1GHz+ CPU's. Anything to look out for??? Memory management. It becomes some what complicated when you start mixing interfaced objects that support reference counting (and thus free them selves when your finished with them), and objects that don't do reference counting (like most of those in the VCL). You get this a lot in Delphi code when you are considering providing interfaced access to GUI components, because the components life time is measured by its owners life time, eg. edit control on a form, but the interfaced usage still makes reference counting calls and you can get into situation where the object needs to be destroyed because its owner is being destroyed, but existing interfaces still exist and need to remain valid. Note that Delphi 6 is going to change this somewhat, because you will be able to define interfaces that don't inherit from IUnknown. I'm not entirely sure how this will change the design decisions that you make, but it will definitely allow more control over your implementation. Cheers, Max. --- 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
Re: RE: [DUG]: Interfaces
Sandeep You can also delegate the inplemenation of an interface in delphi So in your case ClassC inherits from ClassA and implements InterfaceB (defined alongside ClassB) ClassC has a subject of Class B which it delegates its implementation of InterfaceB to ie TClassC - class(TClassA, InterfaceB) private FClassB: TClassB property InstClassB read FClassB write FClassB implements InterfaceB end I think this is called a 'decorator' patten Neven - Original Message - From: Sandeep [EMAIL PROTECTED] To: Multiple recipients of list delphi [EMAIL PROTECTED] Sent: Wednesday, 13 June 2001 14:19 Subject: Re: RE: [DUG]: Interfaces How do interfaces help i n multiple inheritence? If I have a ClassA and ClassB then if I want to inherit ClassC from ClassA its simple. But if I want to inherit from ClassA and ClassB then using interface I have to implement all the functions in ClassB again in ClassC, so how does it makes life simple? Sandeep Software Developer CFL [EMAIL PROTECTED] http://www.cfl.co.nz -- - 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 --- 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
RE: RE: [DUG]: Interfaces
Neven MacEwan quite correctly points out: You can also delegate the inplemenation of an interface in delphi snippage ie TClassC - class(TClassA, InterfaceB) private FClassB: TClassB property InstClassB read FClassB write FClassB implements InterfaceB end But if you are doing any COM work you must be extremely careful using this sort of mechanism. There is a assumption in COM that objects being the same can be checked by comparing the IUnknowns of two interfaces to see if they are the same. So in the above example casting to InterfaceB and then to IUnknown must produce the same result as just casting to IUnknown. See http://www.techvanguards.com/com/tutorials/tips.asp point 12 for a more detailed explanation. Cheers, Max. --- 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
Re: RE: [DUG]: Interfaces
Neven MacEwan quite correctly points out: You can also delegate the inplemenation of an interface in delphi snippage ie TClassC - class(TClassA, InterfaceB) private FClassB: TClassB property InstClassB read FClassB write FClassB implements InterfaceB end But if you are doing any COM work you must be extremely careful using this sort of mechanism. There is a assumption in COM that objects being the same can be checked by comparing the IUnknowns of two interfaces to see if they are the same. So in the above example casting to InterfaceB and then to IUnknown must produce the same result as just casting to IUnknown. See http://www.techvanguards.com/com/tutorials/tips.asp point 12 for a more detailed explanation. The example at that site is talking about a property which actually returns the interface whereas Neven's example has a property which returns an object (which presumably implements the interface). Does the problem still apply in this situation under Delphi 5? That is, when you have ClassC.QueryInterface(InterfaceB) does this return the interface from the TClassB object rather than an interface which is associated with the TClassA object? Seems to me it depends on how Delphi is choosing to do the internals of the implements keyword and it would certainly be interesting to know. David. --- 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
Re: RE: [DUG]: Interfaces
If I have to redeclare all the methods in interface in the descended class then why not get rid of interface and I still have the same thing. It's not the same thing. Just because you have implemented methods Quack(), and Walk() doesn't mean that a client application expecting to use your object via the IDuck interface will recognise you as a Duck. Interfaces give you a way to identify your capabilites to outside applications.Exporting a particular interface is a contract to provide some well-defined package of functionality in a predictable way. What's wrong with that? Nothing. -ns --- 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
RE: [DUG]: Interfaces Again ;)
Try this nasty example (excuse the syntax etc ) function TMyObject. _Release: Integer; stdcall; begin If FMyInterface.RefCount 1 then//Still plenty of references, just decrement count FMyInterface._Release // Assumes FMyInterface is declared in TMyObject as the // delegation object with the required interface else begin FMyInterface._Release; // This will cause MyInterface to destroy itself // or use FMyInterface := nil // This is better in D3/D4 - it also calls _release and ensures you can test for nil to see if we still have a delegation object. Destroy; // Get rid of myself as well. end; end; If using D4 I tend to put stuff in BeforeDestruction to release/destroy the delegation object just in case the reference counts have been stuffed up and I know it's no longer required as the holder object is about to destory itself. This help stop AV's and stackoverflows on destruction, especially if message handling/waiting can be involved. Myles. -Original Message- From: Aaron Scott-Boddendijk [SMTP:[EMAIL PROTECTED]] Sent: Monday, April 12, 1999 2:21 PM To: Multiple recipients of list delphi Subject:Re: [DUG]: Interfaces Again ;) If you have done it right, there should not be a problem. In your example, when you create your delegation object - In your TMyOBject.Create you need to have a ._addref on your delegation object, ie TMyOBject holds a reference to your object. When TMyObject is destroyed, in it's destructor you do a _release - actually with D3/D4 you assign nil to your reference which then calls _release for you, hence you delegated object is then destroyed when it's holder object is destroyed - or you specifically destroy the delegation object - be careful here with AV's. So the problem then boils down to a normal lifecycle maintenance of your holder object. Your example X := TMyObject.Create; is not what I would recommend. You could perhaps fudge it in that when ITesting calls _release - when it goes out of scope in your simple example, in TMyObject._release you could check and see if it will cause the delegation object to be destroyed and then destroy yourself (Not very nice but can work). Does that all make sense?? It appears that it's not practical to add reference counting to a non-interfaced object by creating a descendant with the iunknown interface delegated then since the interface release only releases the delegated object. Is there some trick I'm missing. Man, this could really use some detailed example code... I'm still pretty sketchy on the management of reference counted instances that delegate instances since you can't drop a parent reference after handing the instance on to a reference of one of the delegated types since you then cause the wrapper instance to be released. The frightening part is the delegated portion keeps on trucking all on its lonesome. -- Aaron Scott-Boddendijk Jump Productions (07) 838-3371 Voice (07) 838-3372 Fax --- New Zealand Delphi Users group - Delphi List - [EMAIL PROTECTED] Website: http://www.delphi.org.nz application/ms-tnef
[DUG]: Interfaces Again ;)
I have a question regarding interface delegation and reference counting.
If a non interfaced object is extended with an interface and that interface uses
delegation to implement that interface then how is instance destruction detected
by the delegating class. Example below
if the following is done.
var
X : ITesting;
begin
X := TMyObject.Create;
end;
at the end of this the TTesting delegated object is destroyed but the Delegating object
(TmyObject) is not released. Suggestions. Classes and interfaces below. I am looking
at how delegation can assist in aggregation but am unsure about management of
instances.
type
ITesting = interface
function Test:String;
end;
TTesting = class(TInterfacedObject,ITesting)
public
function Test :String;
end;
TMyObject = class(TObject,ITesting)
private
FTesting :TTesting;
property Tst:TTesting read FTesting implements ITesting;
public
constructor Create;
end;
implementation
{ TTesting }
function TTesting.Test: String;
begin
result := 'Tested';
end;
{ TMyObject }
constructor TMyObject.Create;
begin
inherited;
FTesting := TTesting.Create;
end;
--
Aaron Scott-Boddendijk
Jump Productions
(07) 838-3371 Voice
(07) 838-3372 Fax
---
New Zealand Delphi Users group - Delphi List - [EMAIL PROTECTED]
Website: http://www.delphi.org.nz
