with CORBA interfaces, the GUID is completly optional since you'll never use it, in this case you just extract an interface with as and the type.Does that mean that corba interfaces are not language agnostic? in sort I can't have interface implemented in other languages than the one the consumer is written in? Sorry but my corba interface knowledge is minimal.
It's not like with QueryInterface() and COM that need to work in an language-agnostic fashion.
Does that mean that corba interfaces are not language agnostic? in sort I can't have interface implemented in other languages than the one the consumer is written in? Sorry but my corba interface knowledge is minimal.
with CORBA interfaces, the GUID is completly optional since you'll never use it, in this case you just extract an interface with as and the type.Does that mean that corba interfaces are not language agnostic? in sort I can't have interface implemented in other languages than the one the consumer is written in? Sorry but my corba interface knowledge is minimal.
It's not like with QueryInterface() and COM that need to work in an language-agnostic fashion.
I still do not understand why this GUID.Yes when I say language agnostic I do mean that in interfaces defined in C++ can be implemented in pascal or basic and used from C++ basic, python, java, or any languages that has library to support them. It is the most usable feature of interfaces it is the feature that used to allow activeX controls to be used from any language including pascal, java etc. A framework build as language agnostic will have to follow very tight specifications it is the same as you writing a dll using only C data types but object oriented.
I do understand interfaces as described in article which vfclist links to in his other topic - http://www.delphibasics.co.uk/Article.asp?Name=Interface (http://www.delphibasics.co.uk/Article.asp?Name=Interface)
I do understand well that this is very useful.
Note that in that article guids are not used!
And then this two posts are more confusing:with CORBA interfaces, the GUID is completly optional since you'll never use it, in this case you just extract an interface with as and the type.Does that mean that corba interfaces are not language agnostic? in sort I can't have interface implemented in other languages than the one the consumer is written in? Sorry but my corba interface knowledge is minimal.
It's not like with QueryInterface() and COM that need to work in an language-agnostic fashion.
Before Object Pascal, I learned about interfaces in Java (with Java I learned object oriented programming). In Java they are much more used then in Object pascal. But I have NEVER seen GUIDs in Java.
What do you mean by "language agnostic"? Are you talking about using interfaces declared in pascal in other languages? How? In which languages? C++, Java? And why? Why would you need interfaces from one language to use in another?
All tutorials about interfaces talk about them like abstract classes, from which then different classes can inherit common functionality.In pascal interfaces is the only working mechanism for "multiple inheritance" as well
But, if I understand correctly, apart from this, interfaces have another completely different purpose?
I still do not understand much about using it in different languages and I am not very interested in that now... but, are these GUIDs actually only for that?For what exactly? As far as I know the role of an ID is to uniquely identify an interface. GUIDs were created in order to make sure that each ID was globally unique avoiding using a registry and all the problems that come with it.
As far as I know the role of an ID is to uniquely identify an interface. GUIDs were created in order to make sure that each ID was globally unique avoiding using a registry and all the problems that come with it.
So how do you propose to ask for a specific interface from a factory for instance?Please keep in mind that you do not write the factory nor have access to its code.As far as I know the role of an ID is to uniquely identify an interface. GUIDs were created in order to make sure that each ID was globally unique avoiding using a registry and all the problems that come with it.
Sorry, I am not following... What ID? What identifying? Without ID, what would you use a registry for?
See the article with which we started "The reason for interfaces" (http://www.delphibasics.co.uk/Article.asp?Name=Interface) - no IDs, no GUIDs. Also, in Java tutorial, section about interfaces (https://docs.oracle.com/javase/tutorial/java/IandI/createinterface.html), again no IDs, no GUIDs.
And I do not see problem with identifying interface
So how do you propose to ask for a specific interface from a factory for instance?
Please keep in mind that you do not write the factory nor have access to its code.
Ah I see. you are not familiar with the meaning of the English language word "interface" which simply means a way to communicate.As far as I know the role of an ID is to uniquely identify an interface. GUIDs were created in order to make sure that each ID was globally unique avoiding using a registry and all the problems that come with it.
Sorry, I am not following... What ID? What identifying? Without ID, what would you use a registry for?
See the article with which we started "The reason for interfaces" (http://www.delphibasics.co.uk/Article.asp?Name=Interface) - no IDs, no GUIDs. Also, in Java tutorial, section about interfaces (https://docs.oracle.com/javase/tutorial/java/IandI/createinterface.html), again no IDs, no GUIDs.
And I do not see problem with identifying interface
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.
Ok let me try to give an example that is closer to pascal object hierarchy. Have you ever used the is operator? EGAh 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 (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 (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 (http://www.freepascal.org/docs-html/current/ref/refch7.html) is the same usage as in Java (https://docs.oracle.com/javase/tutorial/java/IandI/createinterface.html).
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? EGDo 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?
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.Ok let me try to give an example that is closer to pascal object hierarchy. Have you ever used the is operator? EGDo 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.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.
But we see that this problem is present with classes as well.
With out the language agnostic part of the interfaces, they provide nothing that an abstract class doesn't already provide.
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?
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?
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.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) (http://www.delphibasics.co.uk/Article.asp?Name=Interface) 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).
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.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.
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).