OSDev.org

The Place to Start for Operating System Developers
It is currently Thu Mar 28, 2024 6:48 pm

All times are UTC - 6 hours




Post new topic Reply to topic  [ 4 posts ] 
Author Message
 Post subject: [CompilerDev] Comments on Inheritan' and Polymorphism design
PostPosted: Thu Jun 09, 2016 1:58 pm 
Offline
Member
Member

Joined: Mon Dec 21, 2009 6:03 pm
Posts: 164
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:
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


Top
 Profile  
 
 Post subject: Re: [CompilerDev] Comments on Inheritan' and Polymorphism de
PostPosted: Thu Jun 09, 2016 4:06 pm 
Offline
Member
Member
User avatar

Joined: Fri Oct 21, 2011 9:47 pm
Posts: 286
Location: Tustin, CA USA
cxzuk wrote:
Code:
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


Top
 Profile  
 
 Post subject: Re: [CompilerDev] Comments on Inheritan' and Polymorphism de
PostPosted: Fri Jun 10, 2016 12:05 pm 
Offline
Member
Member

Joined: Wed Jun 03, 2015 5:03 am
Posts: 397
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 :)


Top
 Profile  
 
 Post subject: Re: [CompilerDev] Comments on Inheritan' and Polymorphism de
PostPosted: Fri Jun 10, 2016 1:16 pm 
Offline
Member
Member
User avatar

Joined: Wed Oct 18, 2006 3:45 am
Posts: 9301
Location: On the balcony, where I can actually keep 1½m distance
The "calling super to enforce functional invariants"-nonsense:
Code:
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 ]


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 4 posts ] 

All times are UTC - 6 hours


Who is online

Users browsing this forum: No registered users and 24 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB © 2000, 2002, 2005, 2007 phpBB Group