Changes in doc/proposals/virtual.txt [50fb7df:c3b96677]

File:

• doc/proposals/virtual.txt (modified) (4 diffs)

doc/proposals/virtual.txt

@@ -87 +87 @@
 first polymorphic parameter).
 
-Instances of a trait are created by wrapping an existing instance of a type
-that implements that trait. This wrapper includes all the function pointers
-and other values required to preform the dynamic look-up. These are chosen by
-the normal look-up rules at the point of abstraction.
+Once a function in a trait has been marked as virtual it defines a new
+function that takes in that trait's reference and then dynamically calls the
+underlying type implementation. Hence a trait reference becomes a kind of
+abstract type, cannot be directly instantiated but can still be used.
 
 One of the limitations of this design is that it does not support double
@@ -98 +98 @@
 is also restricted, initially forbidden, see extension.
 
-Ownership of the underlying structure is also a bit of a trick. Considering
-the use cases for trait object, it is probably best to have the underlying
-object be heap allocated and owned by the trait object.
-
 Extension: Multi-parameter Virtual Traits:
 
@@ -161 +157 @@
 context, for instance if the cast occurs on the right hand side of an
 assignment.
-
-Function look-up follows the same rules as relaxed (behavioural) inheritance.
-Traits can be upcast and down cast without losing information unless the
-trait is cast down to a structure. Here there are two options.
-
-  Abstraction Time Binding: The more efficient and consistant with other parts
-of CFA. Only the trait types use dynamic look-up, if converveted back into a
-structure the normal static look-up rules find the function at compile time.
-Casting down to a structure type can then result in the loss of a set of
-bindings.
-  Construction Time Binding: For more consistant handling of the virtual
-structs, they are always considered wrapped. Functions are bound to the
-instance the moment it is constructed and remain unchanged throughout its
-lifetime, so down casting does not lose information.
-
-(We will have to decide between one of these two.)
 
 Extension: Multiple Parents
@@ -225 +205 @@
 
 We have so far been silent on how the vtable is created, stored and accessed.
-The vtables for the two types might be handled slightly differently and then
-there is also the hierarchy data for virtual casts.
-
-The hierarchy data is simple conceptually. A single (exactly one copy) pointer
-for each type can act as the identity for it. The value of the pointer is
-its parent type, with the root pointer being NULL. Additional meta-data
-can accompany the parent pointer, such as a string name or the vtable fields.
-
-They types of each vtable can be constructed from the definitions of the
-traits (or internal nodes). The stand alone/base vtable is the same for both
-kinds of inheritance. It may be argumented differently however (include parent
-/this pointer in hierachal inheritance).
-
-Creation of the actual vtable is tricky. For classical single implementation
-semantics we would assemble the functions and create one vtable at compile
-time. However, not only does this not give CFA-like behaviour, it is
-impossible generally because types can satify assertions in different ways at
-different times and stop satifying them. A special set of harder rules could
-be used, instead we have decided to try creating multiple vtables for each
-type. The different vtables will all implement the same type but not always
-in the same way.
-
-Storage has some issues from creation. If the contents of every vtable could
-be determained at compile time they could all be created and stored
-statically. However since thunks can be constructed on the stack and become
-the best match, that isn't always possible. Those will have to be stored in
-dynamic memory. Which means that all vtables must be stored dynamically or
-there must be a way to determain which ones to free when the trait object is
-destroyed.
+
+Creation happens at compile time. Function pointers are found by using the
+same best match rules as elsewhere (additional rules for defaults from the
+parent may or may not be required). For strict virtual this must happen at the
+global scope and forbidding static functions, to ensure that a single unique
+vtable is created. Similarly, there may have to be stricter matching rules
+for the functions that go into the vtable, possibly requiring an exact match.
+Relaxed virtual could relax both restrictions, if we allow different vtable
+at different conversion (struct to trait reference) sites. If it is allowed
+local functions being bound to a vtable could cause issues when they go out
+of scope, however this should follow the lifetime rules most C programs
+already follow implicitly.
+
+Most vtables should be stored statically, the only exception being some of
+the relaxed vtables that could have local function pointers. These may be able
+to be stack allocated. All vtables should be immutable and require no manual
+cleanup.
 
 Access has two main options: