Changeset 88177cf for doc

Timestamp:

Jun 23, 2017, 3:26:01 PM (8 years ago)

Author:

Andrew Beach <ajbeach@…>

Branches:

ADT, aaron-thesis, arm-eh, ast-experimental, cleanup-dtors, deferred_resn, demangler, enum, forall-pointer-decay, jacob/cs343-translation, jenkins-sandbox, master, new-ast, new-ast-unique-expr, new-env, no_list, persistent-indexer, pthread-emulation, qualifiedEnum, resolv-new, with_gc

Children:

376ccadc, 4c03e63

Parents:

653f2c7

Message:

Refinement of the tagged-struct proposal.

File:

• doc/proposals/tagged-struct.txt (modified) (3 diffs)

doc/proposals/tagged-struct.txt

@@ -14 +14 @@
 say which of the possible values is currently stored in the union. The idea
 here is similar, however the possibilities are more open ended.
+
+Alternate names include virtual structure and abstract structure.
 
 
@@ -36 +38 @@
 their parent's fields to their field list so they can be upcast.
 
+The type field may be public, if it is then it can be accessed through a
+simple field access "instance.type". The type field would then be able to be
+used to access the type object, which contains the information for the type.
+It may just be a pointer to the type object "*instance.type", although a
+lookup function could also be used.
+
+
+Usage:
+
+The central feature for tagged structs is a checked cast between pointer types
+to the structures. A cast is successful if the true type of the pointed object
+is of the type being cast to or any of its children, otherwise the cast
+returns null.
+
+The type field should also allow for equality comparison of types.
+
+Currently, with only these operations (and similar features) the type field
+could be hidden and the operations given through helper functions. However
+if the type object has more complex (or even open ended) information in it
+than providing direct access becomes very valuable.
+
 
 Implemenation:
 
-Adding to the field list is a simple matter, should be doable during
-translation. The type field is just a pointer to a type object. With proper
-linking we can create a single unique instance of the type object for each
-declared tagged struct. The instance's address is used as an id for the type.
-It also holds data about the type, such as its parent's id/a pointer to the
-parent type object.
+Adding to the field list would have to be handled during translation. The
+simple act of adding declarations should not be difficult, althought it might
+take a bit of work to find the parent's declarations.
 
-The type field could be hidden (as best as C can hide it) or it could be
-visible to the user with easy access to allow the user to examine the type
-object directly.
-
-Direct access is more useful if the data on the type-objects can change, other
-wise the build in function could handle all cases. Perhaps each root object
-can specify a type object to use or the type objects are themselves tagged,
-although there may not be a base case with the latter.
-
-In the simplest case the type object is a pointer to the parent type object.
-Additional data could be added, such as a name, or a function pointer to the
-destructor.
+Type objects are also simple in to generate, they should just be global
+(program lifetime) structures. Getting there to be exactly one instance of
+each allows the pointer to the structure to be used as the type id, and that
+should be possible to do during linking.
 
 
@@ -94 +106 @@
 If unions are declared tagged instead of creating a new tagged type, all
 possible values of the union must be of that tagged type or a child type.
+
+
+Custom Type Objects (Extention):
+
+Some method to define type objects used within a tree of types. One option is
+to allow the tree's type object to be specified by the tree root. It would
+then have to be filled in for each type in the tree, including the root.
+
+The only required field is the parent field, a pointer to the type object's
+type. (This is also the only required field on the tagged structure itself.)
+
+A further extention could allow expanding type objects, so child types could
+append fields to their parent's feild list. They might need their own type
+objects at that point, or maybe static checks will be enough to see the
+minimum field list.