( ) Relative Definitions ( )

In what I explained to you until now, every time you put a definition, it was added to the class containing it, like this:
&=top
&=middle This class is child of top &&
&&

However, there are times where a class would need to add a child to another class.
For instance, a class might be responsible for a set of objects. A program class is responsible for the list of global variables, for the list of procedures; a procedure is responsible for its code...

This means that if for instance a class wants to add a global variable, then it should add a child to the program.

Amool allows you to add (not set) children to any class (as long as it does not attempt to go through a blocking class, see below)

Syntax

In the same way as you can put a path to read a class (@'program.versionNumber), you can put a path to write a class. (But only for adding definitions: &+ and not &=)

For instance:
&+'program.procedures (some procedure definition here) &&
This would add the definition to the symbol @procedures of the nearest @program subclass (note the tick before program)

Definitions are inherited, not children

This is an important thing to note. A class is defined with its text contents as well as its definitions; children that it recieves from outside are not part of it.

This implies serveral things:

• Subclasses of the declaring class will inherit of these definitions, and therefore also propagate them;
• Subclasses of the class recieving those children will not inherit those added children;
• Suppressing (eg, redefining) the declaring class will cause these added children to be suppressed as well.

Blocking Classes

A system without restrictions like this one would give the classes more liberty than what is wanted.
For instance a class should not be able to add children to the @amool class! Actually, for efficiency reasons, the class defined by a file should not be allowed to propagate children out of the file (because the system has to load the file to see its definitions!)

This behaviour is handled by the concept of blocking classes. A blocking class forbids any propagation to get from inside it to the outside.
In particular, all files are blocking classes, so they can't add children to other files or directories.

Now, you might want sometimes to force a class to be a blocking class.
For instance, you are defining a generic class, that will be the superclass of a set of classes that all make the same relative definition (eg. adding some variable to the main program), so you will put that definition in that generic class so that it is inherited. But you don't want that very definition in the superclass to be connected (it would add a kind of blank variable to the program), so a good solution is to make that generic class a blocking class.

Syntax: to set a class to be blocking, you need to put an exclamation mark (!) just before the path, like this:
&=!ding I am a blocking class && , or
&+!'program.dong I am another blocking class &&

Broken paths

Sometimes, when following the path for a class, the compiler will reach a symbol that does not exist. For instance, when looking for a subclass (eg. &+'program.whatever), there might not be any parent matching this, or when looking for a child (eg. &+one.two ), there might be not any child of that name.

When the path to the child is broken, then it will not be attached anywhere.

Inheriting Relative Definitions

Putting a relative definition directely in the final class is not really useful, as you could also have defined it directely in the class to which it must be attached.
Where this feature is getting really interesting and powerful is when you inherit relative definitions

You will typically put a class on its own making lots of definitions assuming the class is part of a big hierarchy, which is not the case, so none of these definitions will be propagated.
Then, you actually make the final project, and somewhere in it, you will put a subclass of the mentionned class. As definitions are inherited, now they will propagate as expected!

A little example:
Think of an Amool class describing the code for a string gadget. You can put in the class a relative definition specifying that you want to add a global variable for that string gadget.
But as that Amool class is not part of a program (as it's designed to produce any string gadget), so this definition won't be propagated.
Now, in your program, you will put somewhere a subclass of that stringGadget class, and that subclass will inherit the variable definition a successfully propagate it to the program

I'll explain in next chapter how you can actually code this, using the @owner class