Hi,

This is an interesting article about interface and multiple inheritance in Java.

http://blog.cleancoder.com/uncle-bob/2015/01/08/InterfaceConsideredHarmful.html

I wonder, how modern Pascal (FreePascal in particular) answer the questions. :)

Regards,

Couldn't he solve it by using a generic class to "implement" register and notify, so he doesn't have to manually duplicate the code?

Jonas

In our previous episode, Bee said:

I don't actually see questions why you shouldn't have interfaces. I only see reasons in those answers that you can do without if you want to add lots of specifications detailing cornercases.

So the question is what one deems more important, a single class entity or simple(r) rules governing them.

Seems the author of the above is in the former camp. Which is good, but as good as the latter IMHO.

Exactly. Interface delegation solves this problem, that is why it was invented.

Something like

Property MyObserved : IFPObserved read FmyObserved Implements IFPObserved;

I have implemented this delegated object in the fpobserver unit (TObservedHook class).

Note that the whole "separation of concerns" argument is IMO nonsense.

The widget needs to know it CAN be observed.
It needs to know that at some points, it needs to notify possible observers. You cannot avoid that, not with interfaces, not with multiple inheritance; This code will be present in either version of the widget.

Michael.

Michael Van Canneyt wrote

Exactly. Interface delegation solves this problem, that is why it was invented.

How does this correspond to the fact that (AFAIK) interfaces are auto-creating, reference-counted and auto-destroying, while classes are not ?

Ore is this just an unrelated additional feature of interfaces ?

-Michael

In our previous episode, Michael Schnell said:

Reference counted and thus auto destroying. They are not autocreating.

Note that interfaces does not necessarily map to the native class type.

Strictly speaking it is possible to have interfaces to some external entity that does not map to the own class type.

Marco van de Voort wrote

They are not autocreating.

???

I seem to remember that I once did a test implementing an arithmetic with interfaces and there was no need to call create. Maybe I am fooled by my old brain.

-Michael

Marco van de Voort wrote

Strictly speaking it is possible to have interfaces to some external entity that does not map to the own class type.

I suppose this is why Borland once invented them: not for the purpose suggested in the "Blog", but to mirror some external windowish stuff within the language.

-Michael

Michael Schnell wrote

reference-counted and auto-destroying

Not ALL interfaces are reference-counted and auto-destroying. You can create CORBA-style interfaces which are _not_ reference counted but still have the full advantage of a interface.

Regards,
- Graeme -

Graeme Geldenhuys wrote

Not ALL interfaces are reference-counted and auto-destroying. You can create CORBA-style interfaces which are _not_ reference counted but still have the full advantage of a interface.

I see.

hence "interface" denotes two language constructs that work decently different :(

The mingling of language features and externally imposed paradigms regarding the word "interface" for me created a hardly understandable mess.

-Michael

Works different, but they are different!
FPC give us the option to use CORBA or "COM" interfaces. I use last, because auto-destroying is very usefull -- I don't see what is wrong with auto-destroying.

For example, this project is object-oriented and interface-based (auto-destroying). No memleaks.
https://github.com/mdbs99/AWS

Best regards,
Marcos Douglas

Marcos Douglas wrote

FPC give us the option to use CORBA or "COM" interfaces.

Neither "COM" nor "CORBA" is something that is imposed by the language, but it's features are due to some external framework.

While "interface" (as discussed in this thread) is a language feature that somehow extends the "class" paradigm.

For me this is very odd.

-Michael

Michael Schnell wrote

Neither "COM" nor "CORBA" is something that is imposed by the language, but it's features are due to some external framework.

I think you miss understood CORBA interfaces. I don’t know why it was named as such in FPC, but it definitely doesn’t require or depend on an external framework or services etc. CORBA interfaces are simply interfaces (language feature) without reference counting (the latter being a Windows COM requirement).

While "interface" (as discussed in this thread) is a language feature that somehow extends the "class" paradigm.

Yes, and a very useful (advanced) language feature. To quote Eric Gamma ― “program to an interface, not an implementation”. This has huge advantages in Object-Oriented Design:

- improves dependency relationships, by reducing them.
- using interfaces means the implementation of the interface behaviour can change without other code needing to change.
- You can easily mix-in new behaviours to an exiting class. No error-prone multiple inheritance required.
- a lot more code reuse because of interface delegation.
- reducing complexity. Small classes can each implement a specific interface. Keeps the class single goal oriented. These classes can then be reused as interface delegates.
- you can query an object to see if it supports an interface, and if so get the interface reference which you can use. Not so easy or clean with inheritance only.
- interface methods can be implemented as private visibility, and it still allows you to use that interface.

I'm sure given more time I can come up with quite a few more benefits, but the above is a quick “off the top of my head” list.

Many don’t full understand interfaces (language feature) because, as I mentioned, it is a slightly more advanced language feature. It also requires more knowledge of OOP and OOD.

Regards,
- Graeme -

In fact I did understand I only am puzzled by the naming "COM" vs "CORBA", that in no way suggest the real (language-) functionality "ref counting" vs "not ref counting"

Yes, and a very useful (advanced) language feature...

OK this might suggest that as well ref counting as not ref counting interfaces do make sens.

-Michael

Michael Schnell wrote

In fact I did understand I only am puzzled by the naming "COM" vs "CORBA", that in no way suggest the real (language-) functionality "ref counting" vs "not ref counting"

I know COM interface come from the need to interact with Windows COM. CORBA (in terms of FPC), I'm not to sure of. You also get XPCOM - also supported by FPC, and I believe this is also a non-reference counted interface.

As for rather using "ref counted" vs "not ref counted" to reference the different interface types (COM and CORBA). Not even that would be a good solution, because you can implement a COM interface that doesn't have reference counting. Simply implement the IInterface (aka IUnknown) methods yourself and remove the reference counting bits. :-)

Regards,
- Graeme -

Am 26.02.2015 15:43 schrieb "Graeme Geldenhuys" <

Since XPCOM was modelled after COM and even uses things like HResult and such I'd assume they use IUnknown as well and thus they would be reference counted.

But even then the compiler will insert calls to these functions.

Regards,
Sven

Am 26.02.2015 15:43 schrieb "Graeme Geldenhuys" <

Since XPCOM was modelled after COM and even uses things like HResult and such I'd assume they use IUnknown as well and thus they would be reference counted.

But even then the compiler will insert calls to these functions.

Regards,
Sven

In our previous episode, Michael Schnell said:

In fact I did understand I only am puzzled by the naming "COM" vs "CORBA", that in no way suggest the real (language-) functionality "ref counting" vs "not ref counting"

IIRC there was discussion back then about having non COM interfaces. Corba interfaces in e.g. Java are usually used manually refcounted.

(I don't know how Delphi implements Corba interfaces, it had a own broker for some time)

Marco van de Voort wrote

(I don't know how Delphi implements Corba interfaces, it had a own broker for some time)

Sorry, but I feel we are loosing tack of the original focus of this thread: "what is a save replacement of multiple inheritance of classes ? "

- Obviously interfaces do this job.

- Seemingly this is independent of interfaces doing ref-counting.

- Maybe other than with classes, ref-counting interfaces is rather safe.

In other words: *language* disregarding external stuff interfaces might *additionally* be useful to handle.

And hence the questions for me are
- how are ref-counting and not ref counting interfaces distinguished when the programmer wants to use either type ? (and does this syntax make sense)
- where/how is this clearly (disregarding external stuff interfaces might *additionally* be useful to handle) documented ?

-Michael

In our previous episode, Michael Schnell said:

Or maybe the rules are simpler, that is a matter of opinion/interpretation

In other words: *language* disregarding external stuff interfaces might *additionally* be useful to handle.

Basic MI like C++ does afaik imply that both sides (that you inherit from) are a class. Now the C++ concept of the root class is rather thin, but that doesn't go for all languages.

IOW in Delphi speak: interfaces don't have to be implemented by a TObject.

I don't know. I guess Michael and Graeme are the main corba interface consumers with the observer stuff. Maybe Martin S. uses it too.

I searched a bit in the FPC codebase, and the observers and lnet (in utils/fppkg/lnet) seem the only places where it is used. The demo (fcl-base/examples/dobserver.pp) for observers uses interfaces in the exact way as you would refcounted interfaces, except of course you need to keep a reference to the class to release memory.

Correct. MSEgui extensively uses corba style interfaces.

Martin

Martin Schreiber wrote

Correct. MSEgui extensively uses corba style interfaces.

Nice.
-Michael (still thinking that using a term like "corba style" for language internals is decently smelly).

Considering that they are activated by the local switch "{$interfaces corba}" (and the reference counted ones by "{$interfaces com}") you hardly can't blame anyone for using these terms...

Regards,
Sven

I did not want to blame mse to use the term, but fpc for forcing anybody to (ab)use it ;-) .

-Michael