| 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 | If a generic/polymorphic type is tagged its tagged would then be shared
|
|---|
| 74 | between all applications of that generic. Internal tags could be used to
|
|---|
| 75 | seperate these structures again, however it seems in most cases simply using
|
|---|
| 76 | the existing type parameters should provide the needed information.
|
|---|
| 77 |
|
|---|
| 78 |
|
|---|
| 79 | Traits:
|
|---|
| 80 |
|
|---|
| 81 | [is_]tagged[_struct](dtype T)
|
|---|
| 82 | True if the given T is a tagged struct of some kind. This promises that it has
|
|---|
| 83 | a type object, but nothing else.
|
|---|
| 84 |
|
|---|
| 85 | [is_]tagged_under(dtype parent, dtype child)
|
|---|
| 86 | True if child is a child type of parent. Requires that both are tagged structs
|
|---|
| 87 | and that child can upcast to parent.
|
|---|
| 88 |
|
|---|
| 89 |
|
|---|
| 90 | Functions:
|
|---|
| 91 |
|
|---|
| 92 | forall(dtype T | is_tagged(T), dtype U | is_tagged(U))
|
|---|
| 93 | T * dynamic_cast(U * value)
|
|---|
| 94 | The cast function, that safely converts the U* into a T*, returning null if
|
|---|
| 95 | the underlying object value points to is not a child type of T. A shorter name
|
|---|
| 96 | might be perfered. The runtime should be no more than linear with the depth
|
|---|
| 97 | of U in the inhiertance tree.
|
|---|
| 98 |
|
|---|
| 99 | bug#11 might require `bool dynamic_cast(T ** dst, U * src)` instead.
|
|---|
| 100 |
|
|---|
| 101 |
|
|---|
| 102 | Tagging Unions (Extention):
|
|---|
| 103 |
|
|---|
| 104 | Using this system as is does not really work if used on unions directly.
|
|---|
| 105 | No new options to the union can be added, as they must be able to upcast.
|
|---|
| 106 | Similarly, if options are removed, writing to an upcast union is invalid.
|
|---|
| 107 | To allow for growth each option would have to be a structure itself.
|
|---|
| 108 |
|
|---|
| 109 | Which brings us to "tagged struct union", ie. a union of tagged structures
|
|---|
| 110 | as opposed to tagging the union itself. This extention acts as a constraint.
|
|---|
| 111 | If unions are declared tagged instead of creating a new tagged type, all
|
|---|
| 112 | possible values of the union must be of that tagged type or a child type. If
|
|---|
| 113 | the tagged type is omitted then they must all be tagged but of any tagged
|
|---|
| 114 | type.
|
|---|
| 115 |
|
|---|
| 116 | As a short cut union_instance->type might get the type object of the loaded
|
|---|
| 117 | value. It should always be the same operation regardless so it saves
|
|---|
| 118 | abritarly picking a branch of the union to get the type object.
|
|---|
| 119 |
|
|---|
| 120 |
|
|---|
| 121 | Type Objects Fields (Extention):
|
|---|
| 122 |
|
|---|
| 123 | Adding fields to the type object allows data to be shared between instances
|
|---|
| 124 | of the same type. Such behaviour could be mimiced by creating a lookup
|
|---|
| 125 | function on the type object pointer, but this may be cleaner and more
|
|---|
| 126 | efficient.
|
|---|
| 127 |
|
|---|
| 128 | The type object fields follow similar rules to the fields on the tagged
|
|---|
| 129 | objects themselves, they must be additive. So any fields present on a
|
|---|
| 130 | type object will be present (and in the same place) on all of its children.
|
|---|
| 131 |
|
|---|
| 132 | This does mean that many type object structure types will have to be auto
|
|---|
| 133 | generated, and traversing up the tree might get a little wierd. That could
|
|---|
| 134 | be symplified by only allowing the root type to specify fields on the type
|
|---|
| 135 | object, so that the type object is consistant throughout that particular tree.
|
|---|
| 136 | And hence the type_object pointers would also be consistant as the type they
|
|---|
| 137 | point to would never change.
|
|---|
| 138 |
|
|---|
| 139 | struct Example tagged {
|
|---|
| 140 | tagged char const * const type_name = "Example";
|
|---|
| 141 | int data;
|
|---|
| 142 | };
|
|---|
| 143 |
|
|---|
| 144 | Creates a tagged structure that has no parent, stores an integer and the type
|
|---|
| 145 | object also has an extra field that stores a string on the type object.
|
|---|
| 146 | This can be accessed by using member access on the type object, as a regular
|
|---|
| 147 | structure.
|
|---|
| 148 |
|
|---|
| 149 | Type object fields will have to allow initialization on their declaration,
|
|---|
| 150 | and declarations of children as well, as they are not assotiated with the
|
|---|
| 151 | later instances of the tagged structure.
|
|---|
| 152 |
|
|---|
| 153 | ...
|
|---|
| 154 | tagged void (*dtor)(tagged Example * this);
|
|---|
| 155 | ...
|
|---|
| 156 |
|
|---|
| 157 | Sub-Extention, not sure how it would work but some way to have a "dynamic"
|
|---|
| 158 | field that is considered the type of the current tagged struct might be useful
|
|---|
| 159 | for things like specifying a deconstructor. In this case, the following code
|
|---|
| 160 | will clean up any child type of Example:
|
|---|
| 161 |
|
|---|
| 162 | Example * ex = get_some_example();
|
|---|
| 163 | ex->type->dtor(ex);
|
|---|