( ) Inheritance in Amool ( )

Subclassing

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.

&=super

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

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

&+Computer
    &+Disk
        I am a disk of @size megs
    &&
    &+Card
        I am a(n) @type Card
    &&

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

Work: @Work
Boot: @Boot
CV3D: @CV3D
Cs3:  @Cs3
Audio: 
&& 

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
	@super
	IN CONTEXT @computer.Work
	I am a disk of	@size	megs
		IN CONTEXT @computer.Work
		900

The compiler saw the sequence Work: @Work
Boot: @Boot
CV3D: @CV3D
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