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.