Abuts
Abuts differ from cells by the fact they contain a list of subObjects abutted one next to the other, and not a list of instances. There is more information in an AbutX (resp. Y): the order of subObjects is important and the leftmost (resp. bottommost) is the first one. Not all cells can be described with Abuts: for example the ones which have overlapping instances. There is no check that the cells abutted have compatible sizes (this check is made in PW).
Abut classes
abutXClass: REF CD.ObjectClass;
abutYClass: REF CD.ObjectClass;
Creating a new Abut object.
CreateAbutProc: TYPE = PROC [subObjects: LIST OF CD.Object ← NIL] RETURNS [newAbut: CD.Object];
CreateNewAbutX: CreateAbutProc;
CreateNewAbutY: CreateAbutProc;
Getting subobjects from an Abut.
GetAbutSubObjects:
PROC [abut:
CD.Object]
RETURNS [subObjects:
LIST
OF
CD.Object];
NARROW error if not an Abut
For solving coordinate system problems
GetLocationOfFirstInstance:
PROC [abut:
CD.Object]
RETURNS [location:
CD.Position ← [0, 0]];
The location is relative to the [0, 0] of the abut in the CD coordinate system.
Indirect
Indirect objects introduce one level of indirection, so that users can store properties both on indirect objects and their source. No new code is necessary for Indirects since they use the expand mechanism. The result of the expansion is never included in the directory, for the expanded cell might be already in another directory. They are used to implement low weight imports in PW.
Indirect class
indirectClass: REF CD.ObjectClass;
Creating a new Indirect object.
CreateIndirect:
PROC [sourceObject:
CD.Object]
RETURNS [indirectObject:
CD.Object];
Creates a new IndirectObject. Returns NIL if sourceObject is NIL.
Lazy
Lazy objects are basically a way of avoiding the static creation of huge cells, by expanding them on demand. All the data structure contained in a Lazy object is a CreateProc returning an CD.Object, and the necessary parameters to apply to this proc, when it is really needed to expand this fake object into an ordinary CD object.
Lazy objects will permit the construction of huge circuits, if they are used so to generate basic bricks. They open the space/time compromise when generating geometry.
It is assumed that the info field contains no CD object, so that changing a cell has no consequence on the Lazy object.
It is also supposed that the createProc computing the geometry of the object is fast enough, so that there is no need to cache it. If it is not the case, the client can use a cache inside the createProc.
Lazy class
lazyClass: REF CD.ObjectClass;
Creating a new Lazy object.
CreateProc: TYPE = PROC [info: REF] RETURNS [obj: CD.Object];
CreateLazy:
PROC [info:
REF, createProc: CreateProc]
RETURNS [newLazy:
CD.Object];
Creates a new Lazy object.
Implementors goodie
Christian believes that the world is made only of silly people. He is probably 95% right, but we assume that we are not such, and it should be painless to create new classes. For example we might want to register twice our programs, and we know that there is a slight change that this may cause a bug.
RegisterClass:
PROC [objectType:
ATOM, expand: CDDirectory.AnotherProc, enumerateChildObjects: CDDirectory.EnumerateChildObjectsProc ←
NIL, replaceDirectChilds: CDDirectory.ReplaceDChildsProc ←
NIL]
RETURNS [objectClass:
REF
CD.ObjectClass];
Yes, it is perfectly legal to run this proc twice!
All the defaults are the one you dream