Changeset e1e4aa9 for doc/proposals


Ignore:
Timestamp:
Jul 20, 2017, 4:04:11 PM (7 years ago)
Author:
Rob Schluntz <rschlunt@…>
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:
21a5dde1
Parents:
c72f9fd
Message:

More cleanup on revised virtual proposal

File:
1 edited

Legend:

Unmodified
Added
Removed
  • doc/proposals/virtual.txt

    rc72f9fd re1e4aa9  
    6666
    6767The keyword trait is optional (by the same rules as the struct keyword). This
    68 is not currently suported in CFA and the lookup is not possible to implement
     68is not currently supported in CFA and the lookup is not possible to implement
    6969statically. Therefore we need to add a new feature to handle having dynamic
    7070lookups like this.
     
    7575
    7676For instance specifying that the drawable trait reference looks up the type
    77 of the first argument to find the implemenation would be :
     77of the first argument to find the implementation would be :
    7878
    7979trait drawable(otype T) {
     
    8484trait and single generic parameter on the function). In more complex cases it
    8585would have to be explicitly given, or a strong convention would have to be
    86 enforced (e.g. implementation of trait functions is always drawn from the 
     86enforced (e.g. implementation of trait functions is always drawn from the
    8787first polymorphic parameter).
    8888
    8989Once a function in a trait has been marked as virtual it defines a new
    9090function that takes in that trait's reference and then dynamically calls the
    91 underlying type implemenation. Hence a trait reference becomes a kind of
     91underlying type implementation. Hence a trait reference becomes a kind of
    9292abstract type, cannot be directly instantiated but can still be used.
    9393
     
    100100Extension: Multi-parameter Virtual Traits:
    101101
    102 This implementation can be extented to traits with multiple parameters if
     102This implementation can be extended to traits with multiple parameters if
    103103one is called out as being the virtual trait. For example :
    104104
     
    122122
    123123To allow down casting strict virtual requires that all traits and structures
    124 involved be orginized into a tree. Each trait or struct must have a unique
     124involved be organized into a tree. Each trait or struct must have a unique
    125125position on this tree (no multiple inheritance).
    126126
     
    148148This gives us an important extra feature, runtime checking of the parent-child
    149149relationship with a C++ dynamic_cast like operation. Allowing checked
    150 convertions from trait references to more particular references, which works
     150conversions from trait references to more particular references, which works
    151151if the underlying type is, or is a child of, the new trait type.
    152152
    153 Extention: Multiple Parents
     153Extension: Multiple Parents
    154154
    155155Although each trait/struct must have a unique position on each tree, it could
     
    161161The restriction being, the parents must come from different trees. This
    162162object (and all of its children) can be cast to either tree. This is handled
    163 by generating a seperate vtable for each tree the structure is in.
    164 
    165 Extention: Multi-parameter Strict Virtual
    166 
    167 If a trait has multiple parameters than one must be called out to be the one
    168 we generate seperate vtables for, as in :
     163by generating a separate vtable for each tree the structure is in.
     164
     165Extension: Multi-parameter Strict Virtual
     166
     167If a trait has multiple parameters then one must be called out to be the one
     168we generate separate vtables for, as in :
    169169
    170170trait example(otype T, otype U) virtual(T) ...
    171171
    172 This can generate a seperate vtable for each U for which all the T+U
    173 implementations are provided. These are then seperate nodes in the tree (or
    174 the root of different trees) as if each was created individually. Providing a 
    175 single unique instance of these nodes would be the most difficult aspect of 
    176 this extension, possibly intractable, though with sufficient hoisting and 
     172This can generate a separate vtable for each U for which all the T+U
     173implementations are provided. These are then separate nodes in the tree (or
     174the root of different trees) as if each was created individually. Providing a
     175single unique instance of these nodes would be the most difficult aspect of
     176this extension, possibly intractable, though with sufficient hoisting and
    177177link-once duplication it may be possible.
    178178
     
    188188};
    189189
    190 Extention: Structural Inheritance
     190Extension: Structural Inheritance
    191191
    192192Currently traits must be the internal nodes and structs the leaf nodes.
    193 Structs could be made internal nodes as well, in which case the child structs 
     193Structs could be made internal nodes as well, in which case the child structs
    194194would likely structurally inherit the fields of their parents.
    195195
     
    201201Creation happens at compile time. Function pointers are found by using the
    202202same best match rules as elsewhere (additional rules for defaults from the
    203 parent may or may not be reqired). For strict virtual this must happen at the
    204 global scope and forbiding static functions, to ensure that a single unique
     203parent may or may not be required). For strict virtual this must happen at the
     204global scope and forbidding static functions, to ensure that a single unique
    205205vtable is created. Similarly, there may have to be stricter matching rules
    206206for the functions that go into the vtable, possibly requiring an exact match.
     
    209209local functions being bound to a vtable could cause issues when they go out
    210210of scope, however this should follow the lifetime rules most C programs
    211 already follow implicately.
     211already follow implicitly.
    212212
    213213Most vtables should be stored statically, the only exception being some of
     
    222222stored along side it.
    223223
    224 This allows for compatability with existing structures (such as those imported
     224This allows for compatibility with existing structures (such as those imported
    225225from C) and is the default storage method unless a different one is given.
    226226
    227227The other is by inlining the vtable pointer as "intrusive vtables". This adds
    228 a field to the structure to the vtable. The trait reference than has a single
     228a field to the structure to the vtable. The trait reference then has a single
    229229pointer to this field, the vtable includes an offset to find the beginning of
    230230the structure again.
     
    233233trait the vtable pointer in the trait reference can then become a single
    234234pointer to the vtable field and use that to recover the original object
    235 pointer as well as retrive all operations.
     235pointer as well as retrieve all operations.
    236236
    237237trait drawable(otype T) {
     
    248248(although they still must be called specially). The vtable field may just be
    249249an opaque block of memory or it may allow user access to the vtable. If so
    250 than there should be some way to retrive the type of the vtable, which will be
     250then there should be some way to retrieve the type of the vtable, which will be
    251251autogenerated and often unique.
    252252
Note: See TracChangeset for help on using the changeset viewer.