( ) The @static reference ( )

Introduction

A single class definition can exist in many places in the final structure. This happens when the parent definition is inherited.
For instance :

&=high
 &=x high &&
 &=y x is @parent.x &&
&&

&=low &=super @parent.high &&
 &=x low &&
&&

&=new_Y &=super @parent.high.y &&
&& 

In this example the single @y definition is found in two different places, one as a child of @high and the other a child of @low. And the code of @y can be evaluated in one of three places, @high.y, @low.y and @new_Y.
The evaluation will lead to :

@high.y	x is high
@low.y	x is low
@new_Y	x is

Now suppose that you would like to refer precisely the code you have at the place it is defined, for instance you put some definition in the parent and want to refer to it (for instance as a superclass), then you would like to tell the compiler you are talking of this very class and not to another view of it, at another place in the tree, where the parent could be anything else.

Let's say that, in the above example, you want, from inside the @y class, to talk about the @x class that has value

high 

The @static pointer

Of course there is a way to do this, and this is using the @static pointer.

Each class has a pointer named @static (in the same way they have @parent and @owner pointers), which points to the class in the context of the defining class, and not in the context of some subclass.

For example, writing @static.parent.x inside the @y class will always return

high 

&=high
 &=x high &&
 &=y x is @static.parent.x &&
&&

&=low &=super @parent.high &&
 &=x low &&
&&

&=new_Y &=super @parent.high.y && @super
&& 

In this modified code, evaluation looks like this :

x is high 

x is high 

x is high 

Inheriting through @static references

The reason why this was introduced is when you want to specify the superclass of some class in a way it can't be overriden you will usually go through the @static pointer. (This is not needed if you are inheriting from an external class) Example :

&=library
 &=theSuperClass (...) &&
 &=aSubClass &=super @parent.theSuperClass && (...)
 &&
 &=anotherSubClass &=super @parent.theSuperClass && (...)
 &&
 &=aDemoPattern
  &=a &=super @static.parent.aSubClass && (...)
  &&
  &=b &=super @static.parent.anotherSubClass && (...)
  &&
  &=c &=super @static.parent.aSubClass && (...)
  &&
 &&
&&

&=test &=super @parent.library.aDemoPattern && (...) && 

The code above is defining something like a library of objects (this is the way a gui system is defined in the Almuist's api, as a library of buttons, text fields, windows etc). It also contains a structure, @aDemoPattern, that subclasses some of the other members of the library. Now if the super paths of these members were not prefixed by @static then the @test subclass would fail. This is because @test is inheriting the children of @aDemoPattern which looks at the parent for their superclass. And of course the parent of @test is not the @library so it wouldn't work.

Note that the members of the library themselves do not use @static, which allows to make subclasses of the @library and extending the @theSuperClass class. This way, all inherited children will inherit the new @theSuperClass instead of the old one.

Referencing the defined children instead of the actual ones using @static

&=high
 &=x high &&
 my very own x is @static.x
 and the one that is my child is @x
&&
&=low &=super @parent.high && @super
 &=x low &&
 of course, my static.x is @static.x
&& 

Evaluation of these classes yields :

 my very own x is high
  and the one that is my child is high 

 my very own x is high
  and the one that is my child is low
 of course, my static.x is low 

@super is implicitly wrapped by @static references

1. look at the super class of the class containing the code and not the one that is the current context (this is because of the first @static ), and
2. look for that @x child inside the super class, and again not inside the current one. This is because of the second @static.