| 1 | Proposal to add simple inhieritance to the language. | 
|---|
| 2 |  | 
|---|
| 3 | Tagged structures allow for dynamic casting between types in a hierarchy. | 
|---|
| 4 | Children (rather pointers to) can be up-cast to their parents, a safe | 
|---|
| 5 | conversion that may recive language level support or even be implicit. | 
|---|
| 6 | Parents can be down cast to their children, which might fail if the underlying | 
|---|
| 7 | object is not of the child type, or a child of that. | 
|---|
| 8 |  | 
|---|
| 9 | This does not however cause dynamic look-up. During function calls the | 
|---|
| 10 | underlying type is ignored, and the pointer type is used to type match the | 
|---|
| 11 | function call. | 
|---|
| 12 |  | 
|---|
| 13 | The name tagged structure comes from tagged union, which carries a value to | 
|---|
| 14 | say which of the possible values is currently stored in the union. The idea | 
|---|
| 15 | here is similar, however the possibilities are more open ended. | 
|---|
| 16 |  | 
|---|
| 17 | Alternate names include virtual structure and abstract structure. | 
|---|
| 18 |  | 
|---|
| 19 |  | 
|---|
| 20 | Syntax: | 
|---|
| 21 |  | 
|---|
| 22 | "struct" name [ "tagged" [ parent-name ] ] "{" fields "}" | 
|---|
| 23 |  | 
|---|
| 24 | The keywords can change (although they currently reflect the concept name | 
|---|
| 25 | closely). More formally, in terms of grammar this adds: | 
|---|
| 26 |  | 
|---|
| 27 | struct-or-union-specifier | 
|---|
| 28 | ... | 
|---|
| 29 | struct identifier tagged { struct-declaration-list } | 
|---|
| 30 | struct identifier tagged parent-identifier { struct-declaration-list } | 
|---|
| 31 |  | 
|---|
| 32 | "tagged" by itself create a tagged structure that is the root of a new tree. | 
|---|
| 33 | It has no parent tagged structure. If "tagged" is used with a parent than | 
|---|
| 34 | that is the parent of this node. | 
|---|
| 35 |  | 
|---|
| 36 | Tagged structures have fields beyond the ones listed. Root tags have a type | 
|---|
| 37 | field added which give the type of the instance. Child tags prepend all of | 
|---|
| 38 | their parent's fields to their field list so they can be upcast. | 
|---|
| 39 |  | 
|---|
| 40 | The type field may be public, if it is then it can be accessed through a | 
|---|
| 41 | simple field access "instance.type". The type field would then be able to be | 
|---|
| 42 | used to access the type object, which contains the information for the type. | 
|---|
| 43 | It may just be a pointer to the type object "*instance.type", although a | 
|---|
| 44 | lookup function could also be used. | 
|---|
| 45 |  | 
|---|
| 46 |  | 
|---|
| 47 | Usage: | 
|---|
| 48 |  | 
|---|
| 49 | The central feature for tagged structs is a checked cast between pointer types | 
|---|
| 50 | to the structures. A cast is successful if the true type of the pointed object | 
|---|
| 51 | is of the type being cast to or any of its children, otherwise the cast | 
|---|
| 52 | returns null. | 
|---|
| 53 |  | 
|---|
| 54 | The type field should also allow for equality comparison of types. | 
|---|
| 55 |  | 
|---|
| 56 | Currently, with only these operations (and similar features) the type field | 
|---|
| 57 | could be hidden and the operations given through helper functions. However | 
|---|
| 58 | if the type object has more complex (or even open ended) information in it | 
|---|
| 59 | than providing direct access becomes very valuable. | 
|---|
| 60 |  | 
|---|
| 61 |  | 
|---|
| 62 | Implemenation: | 
|---|
| 63 |  | 
|---|
| 64 | Adding to the field list would have to be handled during translation. The | 
|---|
| 65 | simple act of adding declarations should not be difficult, althought it might | 
|---|
| 66 | take a bit of work to find the parent's declarations. | 
|---|
| 67 |  | 
|---|
| 68 | Type objects are also simple in to generate, they should just be global | 
|---|
| 69 | (program lifetime) structures. Getting there to be exactly one instance of | 
|---|
| 70 | each allows the pointer to the structure to be used as the type id, and that | 
|---|
| 71 | should be possible to do during linking. | 
|---|
| 72 |  | 
|---|
| 73 |  | 
|---|
| 74 | Traits: | 
|---|
| 75 |  | 
|---|
| 76 | [is_]tagged[_struct](dtype T) | 
|---|
| 77 | True if the given T is a tagged struct of some kind. This promises that it has | 
|---|
| 78 | a type object, but nothing else. | 
|---|
| 79 |  | 
|---|
| 80 | [is_]tagged_under(dtype parent, dtype child) | 
|---|
| 81 | True if child is a child type of parent. Requires that both are tagged structs | 
|---|
| 82 | and that child can upcast to parent. | 
|---|
| 83 |  | 
|---|
| 84 |  | 
|---|
| 85 | Functions: | 
|---|
| 86 |  | 
|---|
| 87 | forall(dtype T | is_tagged(T), dtype U | is_tagged(U)) | 
|---|
| 88 | T * dynamic_cast(U * value) | 
|---|
| 89 | The cast function, that safely converts the U* into a T*, returning null if | 
|---|
| 90 | the underlying object value points to is not a child type of T. A shorter name | 
|---|
| 91 | might be perfered. The runtime should be no more than linear with the depth | 
|---|
| 92 | of U in the inhiertance tree. | 
|---|
| 93 |  | 
|---|
| 94 | bug#11 might require `bool dynamic_cast(T ** dst, U * src)` instead. | 
|---|
| 95 |  | 
|---|
| 96 |  | 
|---|
| 97 | Tagging Unions (Extention): | 
|---|
| 98 |  | 
|---|
| 99 | Using this system as is does not really work if used on unions directly. | 
|---|
| 100 | No new options to the union can be added, as they must be able to upcast. | 
|---|
| 101 | Similarly, if options are removed, writing to an upcast union is invalid. | 
|---|
| 102 | To allow for growth each option would have to be a structure itself. | 
|---|
| 103 |  | 
|---|
| 104 | Which brings us to "tagget struct union", ie. a union of tagged structures | 
|---|
| 105 | as opposed to tagging the union itself. This extention acts as a constraint. | 
|---|
| 106 | If unions are declared tagged instead of creating a new tagged type, all | 
|---|
| 107 | possible values of the union must be of that tagged type or a child type. | 
|---|
| 108 |  | 
|---|
| 109 |  | 
|---|
| 110 | Custom Type Objects (Extention): | 
|---|
| 111 |  | 
|---|
| 112 | Some method to define type objects used within a tree of types. One option is | 
|---|
| 113 | to allow the tree's type object to be specified by the tree root. It would | 
|---|
| 114 | then have to be filled in for each type in the tree, including the root. | 
|---|
| 115 |  | 
|---|
| 116 | The only required field is the parent field, a pointer to the type object's | 
|---|
| 117 | type. (This is also the only required field on the tagged structure itself.) | 
|---|
| 118 |  | 
|---|
| 119 | A further extention could allow expanding type objects, so child types could | 
|---|
| 120 | append fields to their parent's feild list. They might need their own type | 
|---|
| 121 | objects at that point, or maybe static checks will be enough to see the | 
|---|
| 122 | minimum field list. | 
|---|