( ) Pointing Classes

(To Do: I will add little diagrams and pictures, too much text & code for now! :o)

First, the definition: A class containing exactely one class call (ie, nothing more, nothing less, in particular no definitions) is called a Pointing Class. Evaluating the class produces the same result as if you evaluated directely the pointed class.

A little easy example :

&=root
 &=target something &&
 &=source @parent.target &&
I am looking for @source
&& 

Evaluting the above example would lead, as you should expect, to the following string:
I am looking for something

You notice that you'd have obtained the same result with that code:

&=root
 &=target something &&
 I am looking for @target
&& 

Evaluating fields of a pointed class

Okay, I already explained you all the above. But where this gets interesting is that when you refer to that pointing class (@source, in the above), you can directely refer to the children of the pointed class. (This means, the pointed context is visible from the pointing context)

Another little example

As a piece of code is better than a thousand word :

&=pointing_example
 &=basket
  &=contents apples and oranges &&
This basket contains @contents .
 &&
 &=bag @parent.basket &&
The bag contains @bag.contents
&& 

Evaluating the code will yield to The bag contains apples and oranges.
Why? Because @bag is a pointing class (it contains exactely one call), which means that the pointed context (@basket) is visible from the pointing context (@bag).
So, when searching the @contents class inside @bag, seeing that the class had no child of that name (there could have been one propagated from elsewhere), it looked at the pointed context (@basket), and found the @contents class.

Pointing Is Not Subclassing

Having read the above, you might think that a pointer class is just another way of subclassing classes. But there is a difference:

• When A is a subclass of B, B's child-definitions are inherited by A.
• When A is pointing to , B's children (ie, all classes that had been propagated to B) are visible at A.

Giving pointers as arguments

As you might already know, the arguments you give to classes are little classes by themselves.
For instance, when you do @sayHelloTo( @your_father &) , you are defining a tiny class that has as contents @your_father.
This means that arguments classes, like the one above can themselves be pointing classes. (The one in the above example actually is a pointing classes, as it contains only one class call.) So, the called class can try to evaluate a child of one of its arguments. This allows you to give not only text strings as arguments, but also more complex objects.

It's time for an example

This example defines a class that takes an argument, and displays some fields of it.
Note that when you are doing such definitions, as Amool is everything but a typed language, the function is expecting its arguments to have some children under same specific names. When doing complex projects, these should be mentionned in the documentation as it is not directely visible from the code

&=thing
 &=showInfo( @person &)
@person.name is a @person.age year old @if( @person.male &, man &, woman &) @% .
 &&

 &+people
  &=name Jack &&
  &=age 36 &&
  &=male true &&
 &&

 &+people
  &=name Anna &&
  &=age 87 &&
  &=male false &&
 &&

@forAll( @people &, &, @showInfo( @people &) &)
&& 

You can see two definitions of the @people symbol, which are given to the @showInfo as argument.
@showInfo expects a class that defines the three fields @name, @age and @male, to which it can then refer.

The result of the above code is:
Jack is a 36 year old man.
Anna is a 87 year old woman.

refering to oneself: The At

In some cases a class might want to send a pointer to itself as argument. This is done with a call with just an "at" (@). This is the same as the this symbol in Java or SmallTalk.
For instance, you could have put this string in the definitions of @people : @parent.showInfo( @ &), and then calling @people would make the class send itself as argument to showInfo...

Something sophisticated: pointers to classes with arguments

Here we are getting a little complicated :-)

I mentionned in the chapter speaking about giving arguments to classes that calling a class with arguments creates a class (that does just exist the time of the call) that defines those arguments. For instance when you do @or( true &, false &) you create a new class extending the internal @or class with two extra definitions, one for each argument (it is technically not a subclass as it inherits the children and not the definitions but let's forget that), And then you evaluate that class.

The great thing now is that a class call with argument is still a class call and therefore a class making nothing else as one class call with arguments is a pointing class. Where this gets interesting is that you can give as arguments classes with arguments, and then these arguments are visible from the called class and also from the pointed class.

(To Be Continued)