Changeset 577659b for doc/proposals


Ignore:
Timestamp:
Jul 6, 2017, 1:37:44 PM (4 years ago)
Author:
Andrew Beach <ajbeach@…>
Branches:
aaron-thesis, arm-eh, cleanup-dtors, deferred_resn, demangler, jacob/cs343-translation, jenkins-sandbox, master, new-ast, new-ast-unique-expr, new-env, no_list, persistent-indexer, resolv-new, with_gc
Children:
9ff56e7
Parents:
52a9004
Message:

Added some more information to the tagged-struct proposal from the emails.

File:
1 edited

Legend:

Unmodified
Added
Removed
  • doc/proposals/tagged-struct.txt

    r52a9004 r577659b  
    7171should be possible to do during linking.
    7272
     73If a generic/polymorphic type is tagged its tagged would then be shared
     74between all applications of that generic. Internal tags could be used to
     75seperate these structures again, however it seems in most cases simply using
     76the existing type parameters should provide the needed information.
     77
    7378
    7479Traits:
     
    102107To allow for growth each option would have to be a structure itself.
    103108
    104 Which brings us to "tagget struct union", ie. a union of tagged structures
     109Which brings us to "tagged struct union", ie. a union of tagged structures
    105110as opposed to tagging the union itself. This extention acts as a constraint.
    106111If 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.
     112possible values of the union must be of that tagged type or a child type. If
     113the tagged type is omitted then they must all be tagged but of any tagged
     114type.
     115
     116As a short cut union_instance->type might get the type object of the loaded
     117value. It should always be the same operation regardless so it saves
     118abritarly picking a branch of the union to get the type object.
    108119
    109120
    110 Custom Type Objects (Extention):
     121Type Objects Fields (Extention):
    111122
    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.
     123Adding fields to the type object allows data to be shared between instances
     124of the same type. Such behaviour could be mimiced by creating a lookup
     125function on the type object pointer, but this may be cleaner and more
     126efficient.
    115127
    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.)
     128The type object fields follow similar rules to the fields on the tagged
     129objects themselves, they must be additive. So any fields present on a
     130type object will be present (and in the same place) on all of its children.
    118131
    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.
     132This does mean that many type object structure types will have to be auto
     133generated, and traversing up the tree might get a little wierd. That could
     134be symplified by only allowing the root type to specify fields on the type
     135object, so that the type object is consistant throughout that particular tree.
     136And hence the type_object pointers would also be consistant as the type they
     137point to would never change.
     138
     139struct Example tagged {
     140        tagged char const * const type_name = "Example";
     141        int data;
     142};
     143
     144Creates a tagged structure that has no parent, stores an integer and the type
     145object also has an extra field that stores a string on the type object.
     146This can be accessed by using member access on the type object, as a regular
     147structure.
     148
     149Type object fields will have to allow initialization on their declaration,
     150and declarations of children as well, as they are not assotiated with the
     151later instances of the tagged structure.
     152
     153        ...
     154        tagged void (*dtor)(tagged Example * this);
     155        ...
     156
     157Sub-Extention, not sure how it would work but some way to have a "dynamic"
     158field that is considered the type of the current tagged struct might be useful
     159for things like specifying a deconstructor. In this case, the following code
     160will clean up any child type of Example:
     161
     162Example * ex = get_some_example();
     163ex->type->dtor(ex);
Note: See TracChangeset for help on using the changeset viewer.