[CompilerDev] Comments on Inheritan' and Polymorphism design

Programming, for all ages and all languages.
Post Reply
cxzuk
Member
Member
Posts: 164
Joined: Mon Dec 21, 2009 6:03 pm

[CompilerDev] Comments on Inheritan' and Polymorphism design

Post by cxzuk »

Heya,

I've had a good think on Inheritance, polymorphism and a type system. Id be grateful on any comments on the design?

* Inheritance is specialization (Found out this is called conforming-inheritance). You can overload a method, but adding methods not declared in the super-class are marked as private and can only be used internally.
* Only a super-classes methods are accessible to a subclass (all variables are private).
* Invariants of the superclass must still be held, including the post-conditions of the superclasses overloaded method.
* Assignment is covariant, Arguments are conceptually copied by value.
* When a subclass overrides a method, it does not "replace" the superclasses method, but overloads it. The argument types of a the subclasses method must be specified to be contravariant (equal or less specialized type). The subclass method must call the superclass method in order to hold its post-conditions.
* A subclasses overloaded method can also alter the return type, but must be covariant (equal or more specialized type).
* We have two types of methods, Queries (that return something), and Commands (that alter the objects state). Queries do not have post-conditions, so no Super call's are necessary.
* Command methods create a chain of overloaded methods, connected via Super <method> calls.

How subtype-polymorphism is achieved
the argument copies are downcasted (if required), from the assignment covariance rule. if this fails, The process is tried with the superclass method, if that fails the super class above that is tried etc. Until none match and the error is passed back to the calling function.

some examples.

Code: Select all

INTEGER specializes REAL

a := new Integer(2)
b := new Integer(1)
c := new Real(3.14)
d := new String("5")

e := a + b // e type is Integer.
f := a + c // a(Integer +) fails, tries Super method (Real +), Argument is downcasted to Real and succeeds, f type is Real
g := c + a // c(Real +), a is downcasted and treated as a Real, succeeds, g type is Real.
h := a + d // Error, d can not be downcasted to Integer or Real.
Any feedback welcome,
Mikey
User avatar
eryjus
Member
Member
Posts: 286
Joined: Fri Oct 21, 2011 9:47 pm
Libera.chat IRC: eryjus
Location: Tustin, CA USA

Re: [CompilerDev] Comments on Inheritan' and Polymorphism de

Post by eryjus »

cxzuk wrote:

Code: Select all

f := a + c // a(Integer +) fails, tries Super method (Real +), Argument is downcasted to Real and succeeds, f type is Real
Is your language statically checked? If so, then when the 2 types are not the same, then you would determine the Most Recent Common Ancestor for the 2 types and make a determination of the legitimacy of the operation with those new types. In fact, your g:= assignment would follow the same rules, as would h:= (which, as you pointed out, would be semantically wrong).

This source was fantastic: https://www.coursera.org/course/compilers
Adam

The name is fitting: Century Hobby OS -- At this rate, it's gonna take me that long!
Read about my mistakes and missteps with this iteration: Journal

"Sometimes things just don't make sense until you figure them out." -- Phil Stahlheber
embryo2
Member
Member
Posts: 397
Joined: Wed Jun 03, 2015 5:03 am

Re: [CompilerDev] Comments on Inheritan' and Polymorphism de

Post by embryo2 »

cxzuk wrote:You can overload a method, but adding methods not declared in the super-class are marked as private and can only be used internally.
Why?
cxzuk wrote:Only a super-classes methods are accessible to a subclass (all variables are private).
Why?

Such restrictions look very inconvenient for those who used to work with OOP languages.
cxzuk wrote:Invariants of the superclass must still be held, including the post-conditions of the superclasses overloaded method.
Isn't it the same as is the case for just calling super class's method from it's overloading counterpart? And if you do not call the ancestor's method then you have additional flexibility of being able to remove the constraint. So, it's call or not to call vs always imposed hard restriction.
cxzuk wrote:Arguments are conceptually copied by value.
How shallow the copy is? What about recursion?
cxzuk wrote:When a subclass overrides a method, it does not "replace" the superclasses method, but overloads it.
If it is possible to call new method then you have the replacement anyway.
cxzuk wrote:The subclass method must call the superclass method in order to hold its post-conditions.
So, it's just like in other OOP languages?
cxzuk wrote:A subclasses overloaded method can also alter the return type, but must be covariant (equal or more specialized type).
You have already said it a few lines above. Why so much emphasis?
cxzuk wrote:We have two types of methods, Queries (that return something), and Commands (that alter the objects state). Queries do not have post-conditions, so no Super call's are necessary.
Is there some bigger theory behind it? Or is it just another "very clever thing that looks as very promising" and without any real justification?
cxzuk wrote:Command methods create a chain of overloaded methods, connected via Super <method> calls.
Does it mean something like - a traditional (as in C) call creates "a chain" of nested calls?
cxzuk wrote:How subtype-polymorphism is achieved
What is the difference between subtype-polymorphism and polymorphism?
cxzuk wrote:the argument copies are downcasted (if required), from the assignment covariance rule. if this fails, The process is tried with the superclass method, if that fails the super class above that is tried etc. Until none match and the error is passed back to the calling function.
It mixes type inheritance with operation overloading. It's not a good idea. And the description of such idea should be much longer, just because it involves two important parts of a language instead of one as is the case for many OOP languages.

And by the way - traditional language descriptions introduce basic ideas first, but you prefer to show just some features instead of a big picture. It's much harder to comment anything represented in such a "bottom-up" manner, because there's no visible rationale for the pieces of something big without something, that connects them together.
My previous account (embryo) was accidentally deleted, so I have no chance but to use something new. But may be it was a good lesson about software reliability :)
User avatar
Combuster
Member
Member
Posts: 9301
Joined: Wed Oct 18, 2006 3:45 am
Libera.chat IRC: [com]buster
Location: On the balcony, where I can actually keep 1½m distance
Contact:

Re: [CompilerDev] Comments on Inheritan' and Polymorphism de

Post by Combuster »

The "calling super to enforce functional invariants"-nonsense:

Code: Select all

class MyList extends List
{
    void add(x) // override that doesn't actually add
    {
        super.add(x); // required by language
        super.remove(x); // language fail
    }
}
"Certainly avoid yourself. He is a newbie and might not realize it. You'll hate his code deeply a few years down the road." - Sortie
[ My OS ] [ VDisk/SFS ]
Post Reply