Hi
You are correct in this:
AFAIK with CORBA way user must handle memory management, so without destroy at end there's a memleak.
However, you can play a little with corba-interfaces, e.g.:
program project1;
{$INTERFACES CORBA}
const { this is instrumental }
SGUIDIExample = '{128CE0DE-B11C-4FEB-89AA-38EC3E79F120}';
type
IExample = interface[SGUIDIExample]
function Obj: TObject;
procedure SomeMethod();
end;
TExampleImplementation = class(TObject, IExample)
private
function Obj: TObject;
public
procedure SomeMethod();
end;
{ TExampleImplementation }
function TExampleImplementation.Obj: TObject;
begin
Result:= Self;
end;
procedure TExampleImplementation.SomeMethod();
begin
Writeln('In TExampleImplementation.SomeMethod();');
end;
var
ie: IExample; { we need a variable of the right type }
o: TObject;
begin
o := TExampleImplementation.Create();
TExampleImplementation(o).SomeMethod(); // Works, but is fairly useless
{ if "o" supports/implements IExample, we get a hold of it and use it... }
if o.GetInterface(SGUIDIExample,ie) then ie.SomeMethod()
else writeln(o.Classname,' does not support IExample');
{ now you have a choice, use either "o" or "ie" NOT both }
ie.Obj.Free; // <--- option 1 \o/\o/\o/
ie:= nil; { no dangling dead references. DON'T TOUCH "o" after this }
...or...
o.Destroy(); // <--- option 2
//
end.
With the extra function, you can send the interface through an entire framework and free it when it's done its job, you don't need to hold on to the creating object.
Works to/from libraries also, I use only corba interfaces in my Plugin Framework, that way I have finer control over the memory-management.
Have fun

Regards Benny