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.
|
---|