various ShagOS and Thesis notebook notes from March, 1997 onward


These notes were all gathered from various parts of my old blue spiral bound notebook that I wrote ShagOS and Thesis notes in from time to time. If you don't like the background color, change it! I left it undefined to aid readability, so it's whatever you've got picked for your default. I think a light shade of grey or white works best.

3/17/97

continued from previous notebook...

Page 1
Classes: 
A container of class B
	can hold objects of class B or D,
		but not A or C.
This means that if D adds new attributes,
	B must have made a provision to store them.
		If a container for B is needed, a container
			for B or A can be used
			if A is generic enough to be capable of this
		Perhaps the hierarchy of classes should not exist?
		-> No, they just should not be subclasses if they are
			not able to be contained in the same parent class
For containers, it's as if the hierarchy is really:


Types:

If a 'b' is needed, a 'd' or 'b' can be used.
Page 2
If I stay with C++ for too long, I could end up like the old PL/I and COBOL legacy programmers...
Default type (default class for type?) should support casting to/from derivable types, and converting to/from persistent storage (flattening)
-> a special type should be used for such conversions, which can handle representing arbitrarily large #'s as strings of bytes or characters, in a given base (by supplying the base and a translation array). Floating point can be specified with two or more such #'s. This way, byte ordering is handled by the generic "packer" instead of by each class. Of course, it's still necessary that the packer object knows the native byte order. Hmm...
The advantage is that the size used by the implementation does not need to be known. But then, fetching each attribute, and telling it to write itself would accomplish the same thing.
Thus, prime attributes for each type should be selected, from which the type can be reconstructed. (Containers could move in memory, though...)
what C++ calls a "class hierarchy" is really an implementation hierarchy-- showing how to build containers for object representations; virtual methods allow access to parts to "see" the object as a whole 
types are classifications based on interface
classes are classifications based on implementation
	
	essentially, both are "classes" of objects in some sense
	an extended implementation may share code and features
		but it is truly a new, distinct class
Page 3
[ Note: it has become standard practice in a lot of these notes to represent types with all lowercase letters, just as variables are, and to represent classes with an initial uppercase letter ]
The Ellipse that is currently a circle may not have the type 'circle' by default but the type circle should support derivations from ellipse and act accordingly.

Types are an abstract way of classifying objects.
Classes are implementation-dependent, and each one only needs to directly support the types it was designed for.

The class used to represent a region of memory controls what types may be represented there, and it also limits it! Numbers are limited to the number of bits the class uses, so it actually provides a subtype, whether or not that was the desired or intended.

Thus, even for a particular abstract type like 'ellipse', no truely complete implementation can exist. To properly conform to the implementations, subtypes need to be created that make the limitations clear:

This unfortunately means that even an algorithm that uses typed object references instead of precise class implementations must inherently have limitations, if there is to be any guarantee of correctness. This is undesireable though, since the nature of the algorithm does not impose these limitations... This will have to be considered further, to find a generalized way of specifying the types while still ensuring that runtime errors won't occur due to numeric overflow.

Page 4

(fixed point is really floating point with the point defined by implementation, so I'm not sure it needs its own separate type, except that it can't be adjusted, so this limits accuracy...)

A container for 'int' probably doesn't really exist. For types used just to read values, overloading based on the sizes seems ridiculous. However, for containers for values, it's important. The substitution hierarchy for containers is reversed from that of reading values:
containers follow c++-style hierarchy
All are classifications of #'s, and any number belonging to a specific type belongs also to the parent type.

Page 5 
Classes are sets of objects that have related characteristics.
Subclasses are sets within those sets
Classes can be instances of other classes,
	meaning that all the classes have some related feature
	Is this any different from subclassing?
There are many more pages to go, but I don't have any more time right now, so this will be appended to when I can get to it... check back in the coming weeks and months for additions.