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); |
---|