Timeline for Are multiple dynamic dispatch methods possible?
Current License: CC BY-SA 4.0
10 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| May 14, 2021 at 18:50 | comment | added | Géry Ogam | ‘The fundamental idea of multiple dispatch is that all arguments that take part in the dispatch are equal’ Yes but equal under dynamic dispatch (selection of an implementation based on the dynamic type of arguments), not under privileged access (access to the internal state of arguments) which is a different concept. To clarify, my question was about whether it is possible to have both dynamic dispatch on all arguments and privileged access to a single argument (i.e. encapsulation: the receiver argument can only access its own internal state, not the internal state of other arguments). | |
| May 14, 2021 at 10:30 | comment | added | Géry Ogam | Coming back to your answer, what you say is that Common Lisp, Dylan and Julia which support multiple dynamic dispatch functions but do not support methods (single or multiple dynamic dispatch) are not object-oriented but procedural (abstract-data-type-oriented) since they break encapsulation by having privileged access to all their parameters instead of one (the receiver object)? | |
| May 14, 2021 at 10:22 | comment | added | Géry Ogam | I agree, my confusion came from the fact that abstract classes cannot be instantiated but can have instances. I realized that there is actually no contradiction: cannot be instantiated means cannot create instances, not instances cannot be created. Abstract class instances can still be created by a concrete subclass. | |
| Jul 23, 2020 at 5:15 | comment | added | Jörg W Mittag |
IFoo foo = new Foo(). foo is an instance of IFoo, i.e. the reference to the object returned by new Foo() is typed as IFoo, and therefore, I can only access members that are defined in IFoo. Since interfaces do not allow the definition of state or private methods, this means that I can only use the public API of foo, and am therefore observing object-oriented encapsulation. If instead, I had Foo foo = new Foo(); Foo bar = new Foo(), then foo would be allowed to access bar's internal representation and private API and vice-versa, meaning they are not objects.
|
|
| Jul 22, 2020 at 19:18 | comment | added | Géry Ogam | You are talking about "instances of interfaces", but I thought that interfaces (abstract classes) could not be instantiated, by definition. | |
| Jul 22, 2020 at 19:10 | comment | added | Jörg W Mittag | "objects" are Objects. So, what you are basically saying is that instances of classes in C++ are not objects. | |
| Jul 22, 2020 at 19:09 | comment | added | Jörg W Mittag | @Maggyero: This has nothing to do with the language. This is part of the definition of OO. In Java, the language specification calls both instances of classes and instances of interfaces "objects". But, those are only objects in the context of Java, going by the definition of OO, only instances of interfaces are actually objects. Instances of classes are Abstract Data Types, precisely because objects (in the Java sense) of the same class can call each other's private methods, whereas interfaces cannot define private methods, so as long as all references are typed as interfaces, all | |
| Jul 22, 2020 at 19:04 | comment | added | Géry Ogam | Thanks Jörg for this interesting answer. You said "It doesn't even have privileged access to other instances of the same type." Are you talking about Java? Because this is not the case in C++ where members and friends of a type have privileged access to members of instances of the same type. | |
| Jul 22, 2020 at 4:31 | history | edited | Jörg W Mittag | CC BY-SA 4.0 |
added 87 characters in body
|
| Jul 22, 2020 at 4:23 | history | answered | Jörg W Mittag | CC BY-SA 4.0 |