ocean-lang.org Git - ocean-D/blob - thoughts

   1
   2 Thoughts about OO types systems.
   3
   4 What is it?
   5 it it enough
   6 how does it relate to current implemented models,
   7   e.g. prototypes
   8 Is it implementable, useful.
   9 Want some terminology:
  10  object, class, subclass, type, subtype, inheritance
  11
  12 want to talk about zones of objects of a type: a pointer can point to
  13 a member of a zone.
  14 Look into islands too.
  15 Try to characterise linked lists and doubly linked lists.
  16
  17
  18 The basic premise of OO is that "computing is done with objects",  or
  19 is that "programing is done with classes"??.
  20 An "object" appears as a record of operations together with some
  21 opaque state. The operations appear similar to functions in that they
  22 accept arguments/parameters, and produce a result. In a typed setting
  23 there will be a signature indicating the allowed types of arguments
  24 and the required type of result.
  25 The operations are not functions because they have the state of the
  26 object as well as the arguments as inputs, and because they may change
  27 the state of the object.
  28
  29 The state of an object is only accessable though the operations that
  30 it contains. The implementation of those operations normally see the
  31 state of the object as a record of state variables which are
  32 themselves objects. The implementation may define further operations on
  33 those state variables, which are visible only within the object or its
  34 descendants (see below).  These are not really "object operations" but
  35 are simple procedures. The two are easily confused, but should not be.
  36
  37
  38 If two objects contain the same set of operations with the same
  39 signatures, then either can be use in place of the other (at least as
  40 far as type correctness is concerned).
  41 More generally, if a piece of code requires an object to supply a
  42 certain set of operations, then any object which supplies those
  43 operations, whether or not they supply others, can be used.
  44 This is called "polymorphism" as objects of many different shapes can
  45 be used in the one place.
  46 This leads to a partial ordering on types of objects where a type A is
  47 <= a type B is any object of type A can be used wherever an object of
  48 type B is required. Applying this recursively gives a useful subtype
  49 relation.
  50
  51 If A<=B and A.x : a->b and B.x:c->d then a>=c and b<=d
  52 It seems tidy to assume that every object responds to every message.
  53 This implies that the top of the type latice which we shall call
  54 "OBJECT" should give signature BOT->OBJECT to every message, where BOT
  55 is the bottom of the type lattice, a subtype of every type.
  56 If we exclude the existance of any BOT object, then such operations
  57 would not be callable, which is what we would like.
  58 Only once the signature has been changed by subtyping to elevate the
  59 argument type will operations be callable.
  60
  61 To make operations a bit more meaningful, we will associate a
  62 specification with each operation. i.e. a precondition and a
  63 postcondition. These will normally need "access" to the state of the
  64 object, which is best described abstractly with variants and an
  65 invariant.
  66
  67 Now, if A<=B and A.x :: [a/b]  and B.x::[c/d] then c->a and b->d.
  68 So the specification for all operations on OBJECT should be
  69 [True/False] == MAGIC.
  70 Similarly operations on BOT have signature OBJECT->BOT and
  71 specification [False/True] == ABORT
  72
  73 Clearly a BOT object is useless so excluding them is not a problem.
  74
  75
  76 Parameterised types:
  77 -------------------
  78  It turns out to be useful to be able to talk about incompletely
  79 specified, or parameterised types. This is similar to parameterised
  80 expressions that we call functions.
  81 So we defined parameterised types:
  82 P ==  lambda x<=T . F(x)
  83 We treat this like a virtual type, i.e. no object have this type, they
  84 only conform to this type.
  85 A conforms to (is a subtype of) this P if there exists some t <= T
  86 such that A <= P t
  87 Of course, P t may be another parameterised type.
  88
  89 Parameterised types are not the same as types, they are only second
  90 class types. A variable/name-binding must have a closed type, not a
  91 parameterised type. A name-binding can have a closed type by applying
  92 a parameterised type to a type variable within another parameterised type.
  93
  94 A word about inheritance:
  95 ========================
  96
  97 The only required relationship between a subtype and its supertype is
  98 that the signatures of all operations be in the same sub/super
  99 relationship, and that the invarient of the subtype imply the
 100 invariantof the supertype. In particular, the state does not need to
 101 be represented in a similar way at all.
 102
 103 However, it is often of practical value to use the implementation of a
 104 super type when implementing the subtype.
 105 In this case the subtype will contain at least the state variables
 106 of the supertype and probably much of the procedure code of the
 107 supertype.
 108 Precisely, any local name binding (local variable or procedure) that
 109 is assumed by any borrowed code must be provide with compatible
 110 signature in the subtypes implementation.
 111
 112 We will call a procedure that only calls operations on the current
 113 object, never observes state directly, a pure procedure.
 114 A pure procedure used as an operation on a supertype can be used as an
 115 operation on any subtype, indepentantly of state storage.
 116
 117 If a subtype only uses pure procedures from its supertype(s) then we
 118 will call this pure inheritance.
 119 If a subtype uses non-pure procedures and/or directly accesses state,
 120 we will call this dirty(?) inheritance. It violates encapsulation.
 121
 122 Both of these types of inheritance follows subtyping.
 123
 124 The literature suggests to thoughts about inheritance which do not
 125 follow subtyping.
 126 They involve co-variance and deviance.":-)"
 127
 128 Co-variance happens when we want the arguements to a operation are
 129 re-typed down the type latice during inheritance.
 130 A typical example is with binary operators. e.g. addition
 131 The super-class can be added to itself, the subclass
 132  can be added to itself, but not to the superclass.
 133 I don't have any really good example through which to address this,
 134 (I don't this point/colour-point makes sense) but I feel that
 135 parameterised types can provide the desired fnctionality.
 136
 137 Deviance is when heavy handed changes are made to operation
 138 signatures, such as removing an operation or changing the signatures
 139 in other non-conformant ways. Given that the type of self gets
 140 modified in such a heavy handed way, it is hard to see that the new
 141 self will make any sense in the context of the originaly operations.
 142 If it does, it can only be (I guess) because there is a common
 143 implicit super type to which both the superclass and the subclass
 144 conform, and the operation of the superclass which are being borrowed
 145 are infact valid for this common super class. I really need some more
 146 examples to understand this better.
 147
 148
 149 Object creation
 150 ===============
 151
 152 A question (prompted by abstract factory patten in 'design patterns')
 153   How are objects created and initialised.
 154   Initialisation is particularly important for immutable objects.
 155  If creation is the result of an operation, the owner of the operation
 156 could be:
 157     1/ an object of same class as the one being created.
 158        This begs the question how was that object created.
 159        This is done in prototype systems by allowing the type of an
 160        object to be modified dynamically by adding operations.
 161     2/ an object which represents the class.
 162        The object would have to be a pre-existing singleton.
 163        Then, what other operations might a class have: what is it's
 164        type.
 165     3/ a "memory" object could create other objects, but how would the
 166        type of the returned object be guarenteed. Also, are we really
 167        concerned with where something is stored, and can't the storage
 168        type of an object change.