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.
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.
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
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.
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
containers follow c++-style hierarchy
All are classifications of #'s, and any number belonging to a specific type belongs also to the parent type.
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?