Hi,

I am reading this:

http://wiki.freepascal.org/How_To_Use_Interfaces

And wondering what's the *purpose* of "reference counting"? While I use interface before in delphi and java, I didn't notice that I need a UUID for interface. I had an impression that it has something to do with COM?

So, what is the purpose of this UUID and the method provided by TInterfacedObject?

Thanks
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20130320/b0b451af/attachment.html>

Delphi (and FPC) implements garbage collection by reference counting. It's used in all dynamic (managed) datatypes, like arrays, interfaces, AnsiStrings...

While I use interface before in delphi and java, I didn't notice that I need a UUID for interface. I had an impression that it has something to do with COM?

Right, an UUID/GUID for interfaces is Windows COM specific.

So, what is the purpose of this UUID and the method provided by TInterfacedObject?

The GUID allows to look up the interface definition when a type library
(*.TLB) exists (on a Windows platform).

DoDi

OK, What confused me is the description found in FPC manual saying:

TInterfacedObject is a descendent of
TObject<http://www.freepascal.org/docs-html/rtl/system/tobject.html>which implements the
IUnknown <http://www.freepascal.org/docs-html/rtl/system/iunknown.html>interface. It can be used as a base class for all classes which need reference counting.
in another word, reference counting is a feature of TInterfacedObject, or the AfterConstruction/BeforeDestruction methods?? it sounds like non-descedants of TInterfacedObject are not reference counted??

2013/3/20 Hans-Peter Diettrich

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20130320/e6939aaa/attachment.html>

Hi,

Dodi covered it all pretty much...

Xiangrong Fang wrote

So, what is the purpose of this UUID and the method provided by TInterfacedObject?

Only needed if you are doing COM programming under Windows. For the rest of the times you don't need it.

Also note that sometimes it is beneficial having interface support, but without reference counting. In that case you can use CORBA-style interfaces.

Simply add the following to your unit..

{$mode objfpc}{$H+}
{$interfaces corba}     // <<--   New line
type
  ITestInterface = interface
    [STestInterface]
    procedure DoSomething;
    procedure DoItAll;
  end;

Now 'interface' in the type declaration will not be a IUnknown or IInterface descendant. Thus no need to use TInterfacedObject as a base class, TObject will suffice. I tend to use CORBA-style interfaces much more in my applications - it allows me to easily add interface support to any of my existing classes.

I also believe that you can mix COM and CORBA style interfaces in your application, but that is probably not a good idea. Best to avoid that.

Regards,
- Graeme -

As a matter of fact, this is what confused me the most. In my previous experience, e.g. with java or php, I don't care about COM or CORBA, interface to me is just another way to implement abstract method for languages that do not support multiple inheritance. Isn't that the case?

The reason I asked the question initially was I try to implement Enumerator for my TTreap class so that I can use it in for... in loop. To do this, can I just implement the GetEnumerator method, or I have to define the class as this:

generic TTreap<TKey, TValue> = class(IEnumerable);

In another word, if I do not declare that the class implements IEnumerable, but just add the required method, will the language detect this and make my class enumerable?

2013/3/20 Graeme Geldenhuys

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20130320/cbf469ad/attachment-0001.html>

No, the reference counting is a feature of IUnknown (or any descendant of it) and is only used if you work with the interface and not the class type. You can implement the IUnknown (or IInterface) interface yourself as well.

Regards,
Sven
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20130320/a3e64213/attachment.html>

The GUID is also necessary if you want to have "as" and "is" support.

Regards,
Sven

TInterfacedObject *simplifies* the addition of interfaces to derived classes, by adding the required interface supporting methods to this base class. For other classes, which are not based on TInterfacedObject, adding interfaces requires that the interface support methods are added explicitly to *every* such class.

The compiler inserts calls to the reference counting methods only when an interface of a class is *really* used in code. Adding such methods to other classes is of no use, because there these methods will never be called.

DoDi

As a matter of fact, this is what confused me the most. In my previous experience, e.g. with java or php, I don't care about COM or CORBA, interface to me is just another way to implement abstract method for languages that do not support multiple inheritance. Isn't that the case?

COM and CORBA are not requirements for using interfaces in Delphi/FPC. These models become important only when an interfaced object is *created* by one process for *use* by an different process, e.g. when you run Word and want to access its documents from your own program. Or when you embed an ActiveX control into your program, and want to communicate with it in some special way (not using the TWinControl methods). In such a scenario you'll have to add much more code, in order to make such distributed processing work (CoInitialize...).

DoDi

Hans-Peter Diettrich wrote

TInterfacedObject *simplifies* the addition of interfaces to derived classes

Just for clarity [to the original poster]... that is only for COM style interfaces and the reference counting part.

CORBA style interfaces have no "required" methods to implement, so in such a case general interface support can be added to a TObject descendant simply by including the interface name in the class declaration.

Regards,
- Graeme -

Does this mean that CORBA interfaces are not reference counted at all, or you use them without reference counting?

DoDi

They are not reference counted. The descinator "CORBA" is misleading anyway.

Martin

Hans-Peter Diettrich wrote

Does this mean that CORBA interfaces are not reference counted at all,

Correct. And as Martin said, the name "CORBA" is a bit misleading. FPC has no CORBA or ORB implementation, so no distributed communications can be done out of the box. The interfaces in that mode [CORBA style], I guess, is just _similar_ to real CORBA apps. The easiest way to explain it is that CORBA style interfaces are just like COM style interfaces, but without reference counting, and no IUnknown methods.

Regards,
- Graeme -

BTW.: Re. COM / CORBA / ORB

Is there a decent way to describe the internal *Language-concept* (Interface, Interfaced object, ....) (i.e. keywords, syntax, features, usability...) independently of paradigms dictated by the environment the executable is supposed to run in and that might provide some useful parameters to the IDE when designing the program ? Based on this, COM / CORBA / ORB might be described as specializations of the concept.

-Michael

I'm not sure whether I understand what you did and want to achieve.

In an Delphi-compatible implementation *all* classes implementing interfaces *must* be reference counted, so omitting this will result in incompatible code.

DoDi

Simply forget about COM/CORBA ;-)

As already mentioned, Delphi interfaces are the workaround for the missing multiple inheritance in OPL, as known from many languages (Java...). Everything else IMO is language/implementation specific.

The lifetime of interfaces and their underlying objects is managed by reference counting in OPL. IMO this is essential for safe use of interfaces, because no holder of an interface reference can know when the underlying object can or should be destroyed.

DoDi

Delphi's interfaces are more than that. They also add reference counting. If you just want plain interfaces like in Java and other languages than you need to use what is called "CORBA" interfaces in FPC.

Only when "COM" style interfaces are used.

Regards,
Sven

Hans-Peter Diettrich wrote

In an Delphi-compatible implementation *all* classes implementing interfaces *must* be reference counted, so omitting this will result in incompatible code.

So what? There are enough people on these lists that don't care whether their code is Delphi compatible or not.

Regards,
Sven

The GUID is also necessary if you want to have "as" and "is" support.

It is?
I have been using interfaces without GUID and as/is works fine. At least as/is Tsomeclass

Benito

Hans-Peter Diettrich wrote

I'm not sure whether I understand what you did and want to achieve.

It simple. I don't care about Delphi, because I use FPC for everything. I needed interfaces to mix in different behaviour into my existing classes, but I didn't need automatic garbage collection (reference counting), so I used CORBA style interfaces. The usage in my code is near identical to COM style interfaces anyway.

MSEgui also uses CORBA style interfaces extensively.

Regards,
- Graeme -

That's because to support "Intf as/is ClassType" internally a hardcoded interface GUID is used which is handled especially by "TObject.GetInterface".

Regards,
Sven

Michael Schnell wrote

parameters to the IDE when designing the program ? Based on this, COM / CORBA / ORB might be described as specializations of the concept.

I'm not sure I understand your question.

COM is Component Object Model and DCOM is Distributed Component Object Model, developed by Microsoft. This only works on the Windows platform. That is how the do ActiveX, and how Delphi does multi-tier support with MIDAS (using DCOM).

CORBA is Common Object Request Broker Architecture. A standard defined by the Object Management Group (OMG), and is a competing technology to DCOM. CORBA works on multiple platforms, and has a lot more functionality that DCOM. eg: CORBA can also be used instead of WebServices, has clearly defined interfaces and objects that are passed around between systems. You can then call methods on those objects - just like classes. This is just the tip of the iceberg of that CORBA can do. BTW: The Gnome desktop environment is built on top of CORBA too. JAVA uses CORBA extensively.

ORB is Object Request Broker. You need this, through which a CORBA application will interact with other objects. Most ORB implementations are commercial, but there is a Delphi implemented version called mtdORB on SourceForge.net, and a few other implementations in other languages.

In terms of Free Pascal and Interfaces support. COM style interfaces simply means they are _compatible_ with Microsoft COM, and are reference counted. CORBA style interfaces are _compatible_ with how interfaces are implemented in the CORBA standard, and there they are not reference counted. Simply using these two types of Interfaces in your applications don't make them dependant on Microsoft COM technology or CORBA technology.

For more information on COM, DCOM, CORBA and XPCOM technologies, search WikiPedia.

Regards,
- Graeme -

Hans-Peter Diettrich wrote

As already mentioned, Delphi interfaces are the workaround for the missing multiple inheritance in OPL,

As you are stating yourself: multiple inheritance does not introduce reference counting and automatic create/destroy of an instance, interfaces obviously are a rather different concept.

-Michael

Sven Barth wrote

If you just want plain interfaces like in Java and other languages than you need to use what is called "CORBA" interfaces in FPC.

Delphi doesn't have CORBA style interfaces like FPC. The work-around in Delphi was to implement TNullInterfacedObject which has the IUnknown signature, but no reference counting is done.

eg:
type
  // non reference counted interface
  TNullInterfacedObject = class(TObject, IUnknown)
  protected
    function QueryInterface(const IID: TGUID; out Obj): longint; stdcall;
    function _AddRef: longint; stdcall;
    function _Release: longint; stdcall;
  end;

{ TNullInterfacedObject }

function TNullInterfacedObject.QueryInterface(const IID: TGUID; out
Obj): longint; stdcall;
begin
  if GetInterface(IID, Obj) then
    Result := 0
  else
    result := integer(e_nointerface);
end;
function TNullInterfacedObject._AddRef: longint; stdcall;
begin
  Result := -1;
end;
function TNullInterfacedObject._Release: longint; stdcall;
begin
  Result := -1;
end;

Regards,
- Graeme -

That is exactly why I think the *language-concept* (here a thingy that provides reference counting, auto-creation and auto-deletion of an instance etc of a classes instance) should be described independently of COM, DCOM, Axtive X, MIDAS and such things that are not related to the language itself, while the language concept/syntax - being useful in itself, anyway, can *additionally* be used to allow the programmer to handle COM, DCOM, Axtive X, MIDAS and such things.

Yep. But IMHO calling them something like "reference counting interfaces" and "not reference counting interfaces" instead of "COM style interfaces" and "CORBA style interfaces" would be a lot more appropriate, as they are defined and usable for completely other stuff as well. In fact the term "interface" is rather misleading (as they are defined and usable for completely other stuff as well), but this of course is a Delphi heritage.

For more information on COM, DCOM, CORBA and XPCOM technologies, search WikiPedia.

Not necessary because (I already know) and *here* I am interested in the language concepts and not in the environment of the IDE or the program to be created.

-Michael

I haven't used (COM) interfaces so far since i didn't found any use for them in my code, but i didn't knew about their reference counting properties. That could save a lot of headaches i have with my 3D world editor's lightmap generation (currently there is some wrong memory deallocation somewhere that crashes the editor in partial lightmap recalculations). I plan to redesign it at some point soon and i was thinking how to handle this. Since there is native refcounting support in FPC it makes things much easier.

However i did a small test and i noticed something that, to me (as someone who hasn't used COM at all) looks a bit weird:

If i do a declaration like

type
  IResource = interface  end;
  TResource = class(TInterfacedObject, IResource) ... stuff ... end;
  TSomething = class
    ...
    Resources: array of TResource;
    ...
  end;

then reference counting doesn't work. However if i change Resources to

    Resources: array of IResource;

then it works. It seems that the compiler checks only the "topmost" type and doesn't check if TResource implements the IResource and thus doesn't do any reference counting. Is this a bug or it is supposed to work this way?

If the latter, is there a way to make the compiler do reference counting on a variable that has a class type which implements an interface instead of a type that is an interface itself? Or is there any other form of reference counted classes?

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20130321/04f6ce9c/attachment.html>

The compiler does not check for any topmost type. It uses reference counting only for variables that are of an interface type not for a class type.

E.g.:

=== example begin ===

var
   i: IInterface;
   t: TInterfacedObject;
begin
   t := TInterfacedObject.Create;
   t.Free;
   // no reference counting is done here
   i := TInterfacedObject.Create;
   i := Nil;
   // reference counting is done here
end;

=== example end ===

Regards,
Sven

If we put accounting the reference counting aspect then interfaces are exactly what it says on the tin: a interface (German: Schnittstelle) to a class. You can see it as a syntactical contract between the class and the code that uses the class. It also allows you to abstract the implementation to achieve low coupling ("always program against an interface"). Also a class can provide multiple different interfaces. This is the core of what "interface" means.

Now FPC and Delphi add two additional concepts to this:
* reference counting for interfaces (in FPC only those that are not declared after a {$interfaces corba} directive)
* the ability to delegate the implementation of the interface to a different class (using the "implements" keyword)

Regards,
Sven

Edit: If we put the reference counting aspect aside then...

Regards,
Sven

Yes, that is what i mean with "topmost" type: if you look at the inheritance as a tree, TInterfacedObject is the topmost (or root, if you think of it as an upside-down tree) of the type hierarchy. In this code

  type
    IBlah = interface ... end;
    TBlah = class(TInterfacedObject, IBlah) ... end;

TBlah is an IBlah, so i'd expect it to behave like IBlah.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20130321/40916f74/attachment.html>

And it behaves like an IBlah, because you can assign a TBlah to every variable or parameter that expects a IBlah.
The point however is that the compiler only inserts calls to AddRef and Release (which are provided by the base interface IUnknown/IInterface and of which every (COM) interface is derived) if the variable you work with is of an interface type.

Regards,
Sven

It's also interesting to be able to state unambiguously whether the use of interfaces in a program pulls in any external libraries or attempts any external communication.

Sven Barth wrote

If we put accounting the reference counting aspect then interfaces are exactly what it says on the tin: a interface (German: Schnittstelle) to a class.

I see.

I once saw an algebra done with certain objects using operator overloading and interfaces. (e.g. Matrix algebra, or operations introduced on file-based objects). Here reference counting / auto-creation / auto deletion is very useful.

Now FPC and Delphi add two additional concepts to this: * reference counting for interfaces (in FPC only those that are not declared after a {$interfaces corba} directive)

Yep.

* the ability to delegate the implementation of the interface to a different class (using the "implements" keyword)

To allow for a kind of multiple inheritance, I supple.

-Michael

Michael Schnell wrote

> * the ability to delegate the implementation of the interface to a > different class (using the "implements" keyword) To allow for a kind of multiple inheritance, I supple.

It kind be used for a kind of multiple inheritance, but it's main purpose is to avoid code duplication.

For more information you can take a look here:
http://www.freepascal.org/docs-html/ref/refse39.html#x91-1010007.4

Regards,
Sven

Thanks, i understand that. My question is, can i somehow make FPC to add AddRef/Release calls also to TBlah so i can use refcounting with a class just like i would use it with an interface? Is there some technical limitation on why this is only done with interfaces and not all objects that descend from a refcounted interface?

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20130321/3734678e/attachment.html>

Kostas Michalopoulos wrote

Thanks, i understand that. My question is, can i somehow make FPC to add AddRef/Release calls also to TBlah so i can use refcounting with a class just like i would use it with an interface?

No. At least not yet (when a new Delphi is released which might be featuring reference counted objects than this is up for discussion again)

Is there some technical limitation on why this is only done with interfaces and not all objects that descend from a refcounted interface?

It's more a logical problem. Assume you have a "TInterfacedObject" which you put into a variable "intf" of type "TInterfacedObject". As long as you use only "intf" there won't be any problem. But once you assign the value of "intf" to e.g. a variable "obj" of type "TObject" you'll have a problem, because the compiler does not know that "obj" contains a variable of type "TInterfacedObject" and thus the compiler can not create any reference counting calls. This way you would (depending on the situation) either create a memory leak or the interface would be freed before you stopped using the instance stored in "obj". So this situation is basically the same as we have today with the difference that we can now clearly say when reference counting will be applied and when not: if the variable is a (COM) interface then reference counting will be applied, otherwise it won't.

Regards,
Sven

The use of interfaces themselves does not pull in any external libaries. They are merely implemented in a way to simplyfy the use of certain libraries.

Regards,
Sven

Michael Schnell wrote

> * the ability to delegate the implementation of the interface to a > different class (using the "implements" keyword) To allow for a kind of multiple inheritance, I supple.

No, is to reuse existing code. You can have one class (say TObserver) that implements a IObserver interface, and that is all that that class does. You can then use the "implements" keyword in another class (eg: TMyObject), and delegate the IObserver implementation to the TObserver class. No need for the TMyObject class to re-implement all the methods that IObserver specifies.

This concept is extremely handy if you implement something like Model-View-Controller (MVP) in Object Pascal and make use of Interfaces. Joanna Carter wrote some articles many years back on implementing MVP using Delphi. She used interfaces and delegation extensively (the most I have ever seen in any code). You can Google her name to find the articles.

Regards,
- Graeme -

Kostas Michalopoulos wrote

properties. That could save a lot of headaches i have with my 3D world editor's lightmap generation (currently there is some wrong memory deallocation somewhere that crashes the editor in partial lightmap

Don't be fooled to think Interfaces is the answer to all memory issues. The use of Interfaces is an "advanced topic". There are many pitfalls you need to look out for when using them.

Regards,
- Graeme -

Ah, ok thanks for the explanations.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20130321/914f014d/attachment-0001.html>

No, i never said that. I said that i have a problem with the way i'm using memory in my code currently (which is the result of the code doing stuff i didn't originally planned - in particular i didn't plan to have partial lightmap calculations) and i want to redesign it. Previously i would do either something like manual refcounting or use some sort of lightmap manager that would take care of managing the memory.

What i'm thinking right now is to simply create the lightmap objects (as interfaces) from the lightmapper side and send them to the 3D world side. My only concern for now is if interfaces are thread safe (that is, what happens if two threads keep a reference for the same object) or i need to do my own locking.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20130321/24d2e98b/attachment.html>

"TInterfacedObject" uses "InterlockedIncrement" and "InterlockedDecrement" to manage the reference count. So on platforms where these two are implemented in a thread safe manner it should be safe to use interfaces in multiple threads.

Regards,
Sven

Thanks for that clarification :-)

Interface delegation is something different from multiple inheritance. The interface implementor and the interfaced object then have nothing in common, the methods of the implementor cannot access elements of the interfaced object.

DoDi

"Using Delphi" is essential, the same won't work with FPC - when the description of FPC "implements" is correct - because FPC then doesn't allow to override selected methods of the delegate.

How should the IObserver know about the observed object?

DoDi

Thanks, i understand that. My question is, can i somehow make FPC to add AddRef/Release calls also to TBlah so i can use refcounting with a class just like i would use it with an interface?

When you declare IBlah and implement it in TBlah, you can use:

var MyBlah: IBlah; //instead of TBlah!
...
   MyBlah := TBlah.Create as IBlah;

Now MyBlah will be destroyed when the last reference to it goes away.

Is there some technical limitation on why this is only done with interfaces and not all objects that descend from a refcounted interface?

Reference counting adds some runtime overhead. If you want all your objects reference counted, then use interface references instead of object references in your code, as outlined above.

DoDi

No :-(

The same considerations apply to the use of object and interface references in threads. Interface methods are implemented by class methods, and consequently must not be called from multiple threads at the same time.

DoDi

There are also enough people who consider to use FPC instead of Delphi, but cannot due to such incompatibilities.

Thanks for giving me insight into the crippled implementation of interfaces in FPC :-]

DoDi

"Hans-Peter Diettrich" wrote

Kostas Michalopoulos schrieb: > Thanks, i understand that. My question is, can i somehow make FPC to add

AddRef/Release calls also to TBlah so i can use refcounting with a class just like i would use it with an interface?

You don't need the "as".

Regards,
Sven
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20130321/8b1395e7/attachment.html>

(as interfaces) from the lightmapper side and send them to the 3D world side. My only concern for now is if interfaces are thread safe (that is, what happens if two threads keep a reference for the same object) or i need to do my own locking.

> > "TInterfacedObject" uses "InterlockedIncrement" and

"InterlockedDecrement" to manage the reference count. So on platforms where these two are implemented in a thread safe manner it should be safe to use interfaces in multiple threads.

references in threads. Interface methods are implemented by class methods, and consequently must not be called from multiple threads at the same time.

Kostas did not write about calling methods, but keeping references. And here the reference counting mechanism can be considered threadsafe.

Regards,
Sven
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20130321/25833a35/attachment.html>

interfaces *must* be reference counted, so omitting this will result in incompatible code.

> > So what? There are enough people on these lists that don't care whether

their code is Delphi compatible or not.

There are also enough people who consider to use FPC instead of Delphi,

but cannot due to such incompatibilities.

Thanks for giving me insight into the crippled implementation of

interfaces in FPC :-]

Why crippled?

Regards,
Sven
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20130321/5a64cb10/attachment.html>

different class (using the "implements" keyword)

>> >> To allow for a kind of multiple inheritance, I supple. > > It kind be used for a kind of multiple inheritance, but it's main

purpose is to avoid code duplication.

> > For more information you can take a look here:

http://www.freepascal.org/docs-html/ref/refse39.html#x91-1010007.4

Interface delegation is something different from multiple inheritance.

The interface implementor and the interfaced object then have nothing in common, the methods of the implementor cannot access elements of the interfaced object.

But with only interfaces you inherit merely the syntactical "interface" while with delegation you can also reuse an existing implementation for that interface.

Regards,
Sven
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20130321/e8ce55c2/attachment.html>

> Thanks for giving me insight into the crippled implementation of interfaces in FPC :-] Why crippled?

When FPC does not allow to use delegation ("implements") together with implementing selected methods, this feature is of no practical use :-(

Also the hype about CORBA interfaces looks like mere eye-candy or obfuscation to me. Delphi interfaces require neither COM nor CORBA, they are only open in either direction.

DoDi

2013/3/21 Hans-Peter Diettrich :

The same considerations apply to the use of object and interface references in threads. Interface methods are implemented by class methods, and consequently must not be called from multiple threads at the same time.

What's the problem calling the same method, even on the same object, at the same time from more than one thread?

Joao Morais

Use an object (class instance) for the same purpose, and you don't have to write additional code as well.

DoDi

2013/3/21 Graeme Geldenhuys :

- Memory leak with circular references
- Some useless inc/dec if you don't use const parameters
- Premature destruction when creating within a const parameter and using it (one inc, one dec) before store the reference permanently
- what more? =)

Joao Morais

It depends on what the method does.

Regards,
Sven

2013/3/21 Sven Barth :

That's exactly my point. The problem isn't the method call.

Joao Morais

There exists at least a bug report about it:
http://bugs.freepascal.org/view.php?id=16531 :)

Also the hype about CORBA interfaces looks like mere eye-candy or obfuscation to me. Delphi interfaces require neither COM nor CORBA, they are only open in either direction.

But some people don't like the reference counting. They want to use interfaces like in other languages to just define a "interface" to a class.

Regards,
Sven

Then either call can interrupt the other one, with unpredictable results. Calling different methods can have the same effect, when e.g. one thread tries to add an entry to a list, and another one to remove an entry.

DoDi

Interfaces are there to abstract away the implementation, because you'll only have access to those methods that the interface defines. This allows for low coupling between components and thus for an improvement of code testability and maintainability.

Regards,
Sven

No, that's only a side-effect.

because you'll only have access to those methods that the interface defines.

You also have access only to the public methods of a class.

This allows for low coupling between components and thus for an improvement of code testability and maintainability.

Decoupling is correct, interfaces can help to break cyclic unit references.

DoDi

+1

Since reference counting must be implemented, it also can be implemented as *not* counting references. Similar to AnsiString constants, which also live forever. A simple _AddRef after creation of an interfaced object achieves almost the same effect.

DoDi

In some sense you are right: Their main purpose is to provide a contract between the implementor and the consumer so that they can communicate, thus the abstraction is indeed only a side effect. See also: http://en.wikipedia.org/wiki/Interface_%28object-oriented_programming%29

But the public methods can be a superset of the methods provided by the interface or the interface methods could only be implemented in private.

Regards,
Sven

But then you need to implement these methods. Here I like CORBA style interfaces very much: just add the interface to any class, implement the methods the interface defines and be done. The same way as it is done in e.g. Java and C#.

And CORBA style interfaces also provide a bit more protection against using the implementation of the interface as they don't allow "as/is ClassType" like the COM style interfaces (they still allow "as InterfaceType/StringConstant" though if the interface has a string constant as a "GUID").

Regards,
Sven

2013/3/21 Hans-Peter Diettrich :

Could you clarify?

Calling different methods can have the same effect, when e.g. one thread tries to add an entry to a list, and another one to remove an entry.

Fully agree, therefore exist TThreadList and the like. These are foreseeable scenarios when shared and sensitive data are touched and need to be managed in a thread safe way.

No problem *calling* the same method from several threads at the same time, afaics.

Joao Morais

Hans-Peter Diettrich wrote

Thanks for giving me insight into the crippled implementation of interfaces in FPC :-]

Sorry, but you seem very confused. The default Interfaces "style" used by FPC is the COM-style interfaces. 100% compatible with Delphi. So I really do not see your problem.

IUnknown & IInterface -> Exactly the same as Delphi TInterfacedObject -> Exactly the same as Delphi

To use CORBA-style interfaces, you need to explicitly tell the compiled to do so, via the {$interfaces corba} directive.

I use plenty of projects that use Interfaces, and that code is shared verbatim between Delphi and FPC. Just take a look at the tiOPF project.

Regards,
- Graeme -

So a mix of "implements" and delegates is supported, in contrast to the documentation?

DoDi

Why *must* reference counting be implemented when you want to use Interfaces? Many other languages also have interfaces with no reference counting.

The CORBA-style interfaces that FPC support also make descendant classes easier to extend. For example

  // this class is supplied by a 3rd party company.
  TMyClass = class(TObject)
    ...
  end;

Now I want to add some functionality to a descendant class in my project, and use interfaces to do it [for whatever reason I see fit]. No problem.

  TMySuperClass = class(TMyClass, IObserver)
  private
    // implement IObserver methods here
  end;

All done!

If reference counting interfaces was the only option, I would be forced to implement IUnknown in the TMySuperClass class.... for what? TMyClass is not a TInterfacedObject descendant, and the 3rd party vendor never had a need for interfaces, so they used the very common TObject base class. I don't need reference counting just to have interfaces support - so based on what you say, reference counting must be forced upon me! And I must do more work in my class by adding IUnknown to the TMySuperClass too.

Regards,
- Graeme -

While I basically agree with your comment, this is not what DoDi meant if you look at his answer to my question what he means with that. His point is the missing possibility to alias only a subset of an interfaces function to a delegate which seems to be supported in Delphi and which is reported here: http://bugs.freepascal.org/view.php?id=16531

Regards,
Sven

Hans-Peter Diettrich wrote

> Interfaces are there to abstract away the implementation, No, that's only a side-effect.

As this is what the syntax provides, IMHO language-wise this is a major "effect". (See the example of creating an Algebra, using interfaces to allow for using the elements (instances of the class) without the need of creating them.)

-Michael

Sven Barth wrote

See also: http://en.wikipedia.org/wiki/Interface_%28object-oriented_programming%29

Why trying to limit the use of interface to "protocols" ?

-Michael

As discussed already multiple times it's too simplified to try to define an object as thread safe or not. The definition of thread safe needs to be much more sophisticated (regarding each method/property, regarding the access to the same or multiple instances of the object).

-Michael

I suppose Strings is a much more common issue here.... (Please don't answer to this right now :-( )

-Michael

Hans-Peter Diettrich wrote

object, > at the same time from more than one thread? Then either call can interrupt the other one, with unpredictable results.

Of course the results are very predictable (but complex). The problem is that they usually are not documented :-) .

-Michael

I'm not limiting it, I'm just saying what the main purpose of the concept "interface" is.

Regards,
Sven

Graeme Geldenhuys wrote

Correct. And as Martin said, the name "CORBA" is a bit misleading. FPC has no CORBA or ORB implementation, so no distributed communications can be done out of the box.

(Well, there is DCOM of course)

The interfaces in that mode [CORBA style], I guess, is just _similar_ to real CORBA apps. The easiest way to explain it is that CORBA style interfaces are just like COM style interfaces, but without reference counting, and no IUnknown methods.

Corba ORB interfaces ARE reference counted. (using incref and decref methods iirc).

The difference was that in Corba it was custom to handle this manually, since keeping references long than necessary meant that the Corba server had to keep the object instance in memory.

But I agree that the name was horribly, horribly chosen. Basically what happened is that there was whining about how windows dependent the IUnknown scheme was, when it was implemented, somebody mentioned Corba as non-Windows possibility. The usual anti Delphi/Windows chorus in the maillist caught on, and suddenly all non-IUnknown interfaces were Corba :-)

The reference counting is purely done for COM purposes, not for direct memory safety collection. Note that all other ref counted types in Delphi can't cause cycles. Interfaces can.

Sven Barth wrote

His point is the missing possibility to alias only a subset of an interfaces function to a delegate which seems to be supported in Delphi

OK, understood. But it still doesn't make FPC's interface support totally unusable. As far as I know, there are two relative small parts missing from FPC's implementation of interfaces. But FPC's interface support is still very functional. I have lots of interface code working under FPC (and lots of that code is shared with Delphi too).

Regards,
- Graeme -

Other languages use different memory management (mark-sweep), where Delphi uses reference counting. Ignoring this difference is comparing apples with oranges.

I don't need reference counting just to have interfaces support - so based on what you say, reference counting must be forced upon me!

Your code may work without reference-counted interfaces, but other code may not, in detail when imported from other languages. So implementing the reference counting methods IMO is the safe way, not using it should be reserved for experts.

And I must do more work in my class by adding IUnknown to the TMySuperClass too.

Dunno whether this is required for bare Delphi interfaces. Reference counting does not require IUnknown, as can be seen with dynamic arrays and strings.

DoDi

This is not the whole story :). For non-corba related stuff raw interfaces were meant. But later we realized that they are not very different from corba interfaces which were the same as raw interfaces but addionally allow an interface id being a string (not only a guid) so we decided not to implement raw interfaces but corba ones only (besides com).

Sven Barth wrote

I'm not limiting it, I'm just saying what the main purpose of the concept "interface" is.

IMHO regarding language features we should not discuss main purpose, but "basic purpose", in order to describe what can be done and what can't be done. Also it should not be discussed wow a language feature can be used in Delphi or in a certain OS, but how it can be used "at all", to allow for the fpc team to implement additional, advanced or more straight forward concepts for the users to benefit from.

-Michel

Delphi's interfaces ALWAYS descend from IUnknown thus one must always have the QueryInterface, AddRef and Release methods implemented.

Regards,
Sven

Can you explain what you mean with that? (perhaps using an example)

Regards,
Sven

Ok, then call it "basic purpose". I don't care regarding the name for that...

Regards,
Sven

Hans-Peter Diettrich wrote

So a mix of "implements" and delegates is supported, in contrast to the documentation?

Just like Sven, I'm also a bit lost in what you mean. An example of the issue would be appreciated.

Regards,
- Graeme -

Hans-Peter Diettrich wrote

may not, in detail when imported from other languages. So implementing the reference counting methods IMO is the safe way, not using it should be reserved for experts.

No, just use the interface implementation (COM or CORBA) based on your needs. You can freely mix the two in the same unit as well - as is shown by the Classes unit (classesh.inc to be exact) in FPC.

"reserved for experts"... As I said before, using Interfaces is considered an _advanced topic_, so when you use them, I assume you know what you are doing.

Dunno whether this is required for bare Delphi interfaces. Reference counting does not require IUnknown,

We are only talking about Interfaces here, not other language types. When it comes to interfaces, Delphi requires IUnknown (IInterface, the base descendant, is an alias to IUnknown). Thus the 3 methods of IUnknown must always be implemented.

Regards,
- Graeme -

Am 25.03.2013 02:30, schrieb Hans-Peter Diettrich: > So a mix of "implements" and delegates is supported, in contrast to > the documentation? Can you explain what you mean with that? (perhaps using an example)

Sorry, I was not clear here. See
http://bugs.freepascal.org/view.php?id=16531

DoDi

Puh... and I had thought there was another problem now ^^

Regards,
Sven

Hans-Peter Diettrich wrote

As already mentioned, Delphi interfaces are the workaround for the missing multiple inheritance in OPL, as known from many languages (Java...). Everything else IMO is language/implementation specific.

I think they are primarily meant for/as external proxy objects. The MI angle is only secondary (or even less important.