Recent

Author Topic: A few questions about Interfaces : Part 2  (Read 7361 times)

Zoran

  • Hero Member
  • *****
  • Posts: 1460
    • http://wiki.lazarus.freepascal.org/User:Zoran
Re: A few questions about Interfaces : Part 2
« Reply #15 on: March 06, 2016, 02:01:26 pm »
Ah I see. you are not familiar with the meaning of the English language word "interface" which simply means a way to communicate.
See for a more specific explanation regarding computing https://en.wikipedia.org/wiki/Interface_%28computing%29.
Point is: in java it has again different semantics from CORBA or even more different from COM.
Three ways to solve a problem. So basically, you are confused because not every type of interface is the same interface type.
It is not really that hard.

Thanks.
I do know the English word, it is the language feature which I think is not described well. My point is that what is written here - http://www.delphibasics.co.uk/Article.asp?Name=Interface and also the usage described in fpc reference manual - http://www.freepascal.org/docs-html/current/ref/refch7.html is the same usage as in Java.
These interfaces, without any attempt to "interface other languages" are very much used in Java. And this has nothing to do with GUIDs, nothing to do with identification and "factories" tazz is talking about.

Sorry, I still don't understand it well, but thank you very much for trying.

marcov

  • Global Moderator
  • Hero Member
  • *****
  • Posts: 7458
Re: A few questions about Interfaces : Part 2
« Reply #16 on: March 06, 2016, 02:17:12 pm »
See also http://stackoverflow.com/questions/9592654/what-are-the-differences-between-implementation-of-interfaces-in-delphi-and-laza/9623502#9623502

And getting an object from a Corba broker is also quite complicated. It just doesn't need much compiler assistance, which is why Corba interfaces are so thin.

taazz

  • Hero Member
  • *****
  • Posts: 5363
Re: A few questions about Interfaces : Part 2
« Reply #17 on: March 06, 2016, 03:25:51 pm »
Ah I see. you are not familiar with the meaning of the English language word "interface" which simply means a way to communicate.
See for a more specific explanation regarding computing https://en.wikipedia.org/wiki/Interface_%28computing%29.
Point is: in java it has again different semantics from CORBA or even more different from COM.
Three ways to solve a problem. So basically, you are confused because not every type of interface is the same interface type.
It is not really that hard.

Thanks.
I do know the English word, it is the language feature which I think is not described well. My point is that what is written here - http://www.delphibasics.co.uk/Article.asp?Name=Interface and also the usage described in fpc reference manual - http://www.freepascal.org/docs-html/current/ref/refch7.html is the same usage as in Java.
These interfaces, without any attempt to "interface other languages" are very much used in Java. And this has nothing to do with GUIDs, nothing to do with identification and "factories" tazz is talking about.

Sorry, I still don't understand it well, but thank you very much for trying.
Ok let me try to give an example that is closer to pascal object hierarchy. Have you ever used the is operator? EG
Code: Delphi  [Select]
  1. if Sender is Tbutton then ....;
Do you understand what "is" checks when called? Now ask your self, if you pass a TButton that is created in a DLL why "is" fails to correctly identify the same class?
Good judgement is the result of experience … Experience is the result of bad judgement.

OS : Windows 7 64 bit
Laz: Lazarus 1.4.4 FPC 2.6.4 i386-win32-win32/win64

Zoran

  • Hero Member
  • *****
  • Posts: 1460
    • http://wiki.lazarus.freepascal.org/User:Zoran
Re: A few questions about Interfaces : Part 2
« Reply #18 on: March 06, 2016, 05:39:56 pm »
Ok let me try to give an example that is closer to pascal object hierarchy. Have you ever used the is operator? EG
Code: Delphi  [Select]
  1. if Sender is Tbutton then ....;
Do you understand what "is" checks when called? Now ask your self, if you pass a TButton that is created in a DLL why "is" fails to correctly identify the same class?

I guess that this can be explained that dll has its own copy of lcl hierarhy and that is the reason that TButton from exe and TButton from dll are seen as two different classes?
All the time I am trying to figure out what it has to do in normal usage, classes from dlls are not the cases I'm talking about. Neither are interfaces, as normal language feature.
But we see that this problem is present with classes as well.

So... I'm just beginning to realize that you use interfaces from dlls (that is what you were talking about when you were talking about other programming languages, isn't that?).


taazz

  • Hero Member
  • *****
  • Posts: 5363
Re: A few questions about Interfaces : Part 2
« Reply #19 on: March 06, 2016, 06:07:57 pm »
Ok let me try to give an example that is closer to pascal object hierarchy. Have you ever used the is operator? EG
Code: Delphi  [Select]
  1. if Sender is Tbutton then ....;
Do you understand what "is" checks when called? Now ask your self, if you pass a TButton that is created in a DLL why "is" fails to correctly identify the same class?

I guess that this can be explained that dll has its own copy of lcl hierarhy and that is the reason that TButton from exe and TButton from dll are seen as two different classes?
Which makes the memory address the ID of the class. Now invent an other ID that will be able to work across processes, executables and libraries after that make sure that there is no conflict between the IDs and then extend it to multiple companies implementing potentially the same interface and you start getting the idea behind the GUIDs.

All the time I am trying to figure out what it has to do in normal usage, classes from dlls are not the cases I'm talking about. Neither are interfaces, as normal language feature.
But we see that this problem is present with classes as well.
Well, pascal units already have an interface part that plays the role of interfaces in other languages the implementation and definition of the class are already separated there is no need for an interface type as well. Interface types in pascal by definition are there to support object implementations in other languages and in extension from DLLs.  With out the language agnostic part of the interfaces, they provide nothing that an abstract class doesn't already provide.
« Last Edit: March 06, 2016, 06:11:57 pm by taazz »
Good judgement is the result of experience … Experience is the result of bad judgement.

OS : Windows 7 64 bit
Laz: Lazarus 1.4.4 FPC 2.6.4 i386-win32-win32/win64

vfclists

  • Hero Member
  • *****
  • Posts: 825
    • HowTos Considered Harmful?
Re: A few questions about Interfaces : Part 2
« Reply #20 on: March 07, 2016, 08:57:32 am »
Concerning the GUID I take it that once a GUID is allocated and committed to some kind of registry, it is not meant to be changed again, ie implementation details might change, but the function signatures should not change again.

But in the case of your own locally developed code can you change the interface whilst retaining the same GUID  so long as all the dependent code is available to be recompiled?
Windows - Lazarus 1.0.8/FPC 2.6.0
Linux - Lazarus 1.4.4 /FPC 2.6.4

Zoran

  • Hero Member
  • *****
  • Posts: 1460
    • http://wiki.lazarus.freepascal.org/User:Zoran
Re: A few questions about Interfaces : Part 2
« Reply #21 on: March 07, 2016, 11:16:50 am »
With out the language agnostic part of the interfaces, they provide nothing that an abstract class doesn't already provide.

Oh, no, with this I dissagree, they do!
They provide a way to define common behaviour for classes which do not have common superclass. It is a very useful feature, as multiple inheritance does not exist in Object Pascal and Java. The link which vfclists gave (again, this one) describes that (see the first section - reason for interfaces).

In Java it is very much used, all over the standard java class libraries. In FPC and Delphi it is not used that much, I don't know why (a bright exception is ZeosLib - many functionalities are implemented with interfaces, I believe it is because Zeos is highly influenced by Java's JDBC library and they used their filosofy).

But in the case of your own locally developed code can you change the interface whilst retaining the same GUID  so long as all the dependent code is available to be recompiled?

As far as I understand now, the GUID-s matter only for exporting them in dynamic libraries/shared objects. When used as a normal language feature (see above), you just don't need them.

marcov

  • Global Moderator
  • Hero Member
  • *****
  • Posts: 7458
Re: A few questions about Interfaces : Part 2
« Reply #22 on: March 07, 2016, 11:38:23 am »
Concerning the GUID I take it that once a GUID is allocated and committed to some kind of registry, it is not meant to be changed again, ie implementation details might change, but the function signatures should not change again.

If you use it with COM yes. If you use it without COM, it is not in a registry, but the functioning of the IS operator might depend on its uniqueness (within the binary).

Quote
But in the case of your own locally developed code can you change the interface whilst retaining the same GUID  so long as all the dependent code is available to be recompiled?

In the case of non COM: all no problem.  In case of COM (Tautoobject?), one registers an interface using an implementation (location of OCX/DLL). In such case if the existing registration is for a different dll (path) as the current one, the old stuff might be used and found.

taazz

  • Hero Member
  • *****
  • Posts: 5363
Re: A few questions about Interfaces : Part 2
« Reply #23 on: March 07, 2016, 11:45:56 am »
With out the language agnostic part of the interfaces, they provide nothing that an abstract class doesn't already provide.

Oh, no, with this I dissagree, they do!
They provide a way to define common behaviour for classes which do not have common superclass. It is a very useful feature, as multiple inheritance does not exist in Object Pascal and Java. The link which vfclists gave (again, this one) describes that (see the first section - reason for interfaces).

In Java it is very much used, all over the standard java class libraries. In FPC and Delphi it is not used that much, I don't know why (a bright exception is ZeosLib - many functionalities are implemented with interfaces, I believe it is because Zeos is highly influenced by Java's JDBC library and they used their filosofy).
Good, I was wandering how long it will take to spot it. Yes multiple inheritance is  the only positive of using interfaces but it requires a shift in code paradigm for proper use. For example you shouldn't use object variables at all the auto ref count will destroy interfaces and leave a bunch of variable pointing to invalid memory addresses. Using corba interfaces is a middle road but after a while you will probably want to use them anyway.
But in the case of your own locally developed code can you change the interface whilst retaining the same GUID  so long as all the dependent code is available to be recompiled?

As far as I understand now, the GUID-s matter only for exporting them in dynamic libraries/shared objects. When used as a normal language feature (see above), you just don't need them.
Wrong guids are the IDs of an interface the same way the class memory address is the ID of a class, with out the GUIDs you are left with unsafe casting to put it on class metaphor, on top of that supports does not work with out a GUID I think both in corba and COM interfaces but that is an assumption I haven't really tested.
Good judgement is the result of experience … Experience is the result of bad judgement.

OS : Windows 7 64 bit
Laz: Lazarus 1.4.4 FPC 2.6.4 i386-win32-win32/win64

marcov

  • Global Moderator
  • Hero Member
  • *****
  • Posts: 7458
Re: A few questions about Interfaces : Part 2
« Reply #24 on: March 07, 2016, 11:51:13 am »
In Java it is very much used, all over the standard java class libraries. In FPC and Delphi it is not used that much, I don't know why (a bright exception is ZeosLib - many functionalities are implemented with interfaces, I believe it is because Zeos is highly influenced by Java's JDBC library and they used their filosofy).

I think there are two main reasons:

- interfaces only came later, when the base RTL and VCL already existed. Therefore TPersistent (the abstract "storage"is a class, not an interface)
- In Java memory management is the same for both, and one can use objects and interfaces mixed. In Delphi one can't.  (only recounted COM interfaces)