( ) Inheritance in Amool ( )


As the "oo" in Amool implies, Classes can inherit from each other.

When a class is subclass from another one, it is like if all children of that superclass where also defined, in the same way, in the subclass.


This is done with a special child named @super. When you define this child, you will make your class a subclass of the value of that child.

I'll explain that in more details later, but there's a small point to note here. As multiple inheritance does not exist in Amool, there can't be more than one definition of @super, and you have to use another symbol to define that child, which is &=super (and not &+super).
This actually means that you are not adding a definition to that child but setting the definition of that child.

Now, you can also refer to that @super child from the class: It is useful if you want to retrieve the textual contents of your super class. Just put @super inside your class.
Something else that might be useful is to refer to a child of your superclass, for instance when you put
Name in my super class is @super.name....

More about the context

I already mentionned the context in Amool. Now there's something that might look a bit weird about it concerning superclasses, but once you grasped it, you should find it natural (I hope) :-)
I said that inheriting from a class is like having all its children defined locally. So when you refer to a child that you have not defined, but that your super class has, the context will be to that child, like if it where yours.
Eg: If a class @up has a child @X, and a class @down inherits from @up (and does not define @X), then calling @X from @down will make the context switch to @down.X (and not @up.X). This is important when a class you call refer to its parent... (see next chapter)

Now, this is still valid when you refer to @super : For instance, writing @super.boo will search for a child named @super.boo in the super class, but the context will still be @down.boo ( @down being the class containing the call, like above).

And, again, when you write @super inside a class, this will run your super class, but the context will remain unchanged

However, there is an exception to this rule: @super is not sought relative to the current context: it is always the super class of the class containing the call!
I am sorry to make this exception, but I needed it. This means, for instance, that if you put @super in a class, and your superclass itself writes @super. the latter will point to the superclass of your superclass

When I explain what the @static calls are, you will see that @super is implicitly replaced by @static.super.staticand you will see that this is actually well defined.

An elaborated example...

I'll explain that "@parent" symbol in next chapter... Just know that, in this case, it refers to the @Computer class

        I am a disk of @size megs
        I am a(n) @type Card

    &+Work &=super @parent.Disk &&
        &+size 900 &&
    &+Boot &=super @parent.Disk &&
        &+size 50 &&
    &+CV3D &=super  &&
        Cybervision 64/3D: @super
        &+type graphic &&
    &+Cs3 &=super  &&
        CyberStorm Mk3: @super
        &+type accelerator &&
    &+Audio &=super  &&
        &+type audio &&

Work: @Work
Boot: @Boot
Cs3:  @Cs3

(The full arrows are inheritance relationships; I underlined the three important classes to make it a little clearer :-)

The output of this class is:

Work: I am a disk of 900 megs
Boot: I am a disk of 50 megs
CV3D: Cybervision 64/3D: I am a(n) graphic Card
Cs3:  CyberStorm Mk3: I am a(n) accelerator Card
Audio: I am a(n) audio Card

I'll try now to explain what happenned.

Work: @Work
IN CONTEXT @computer
IN CONTEXT @computer.Work
I am a disk of @size megs
IN CONTEXT @computer.Work

The compiler saw the sequence Work: @Work
Boot: @Boot
Cs3: @Cs3
Audio: @Audio

so it pasted the Work: Boot: and so on directely to the output, and translated the @Work, @Boot, and so on. All these symbols where seen in the context of the @Computer class. And all where found as children of that class.

For translating @Work, for instance, the compiler changed the context to the class @Computer.work, and went through its contents, which is just @super. So, without changing the context (because it's @super and not just any child), it went through the contents of its super class. @super being defined as @parent.Disk, it found the class to be @Computer.Disk (as the class @parent, seen from @Computer.Boot, is @Computer, and then @Disk seen from there is just a regular child).
Now, it evaluated the contents of that: I am a disk of @size megs
Simple text was simply pasted to the output, and @size was evaluated according to the current context, which is still @Computer.Boot. And there's just a child named therein, which has as value 900. So that text is evaluated.

And about the same happened for each of the five children of Computer

Woosh, that was hard :-)

Some remarks before I go on

You must not have cyclic dependencies with superclasses, eg @A subclass of @B subclass of @C subclass of @A. I am not sure if I will forbid it or just put warnings, but anyway I don't see of what use it could be :-)
When you do not specify the superclass, then it will have @amool as default value. (Details about that in the builtin chapter)

Now I think it's time I really explain to you the difference between &+ and &=...
As I told you, &+something adds a definition to the symbol something; and &= sets the definition of the symbol something.
This means that if there were already definitions for that symbol, then the addition operator will just add one defintion, but the set operator will erase (override) all other definitions.

This gets important with inheritance, because you can that way replace some definition that your super class might have done with yours, using the &= operator.
Of course, nothing prevents you from adding (&+) definition after having set (&=) one.

Starting from now, I shall use &= for children meant to be unique

Maxime Gamboni <> Last compiled : Wed Apr 23 21:53:39 CEST 2003