Changeset 58fe85a for doc/proposals/vtable.md

Timestamp:

Jan 7, 2021, 3:27:00 PM (5 years ago)

Author:

Thierry Delisle <tdelisle@…>

Branches:

ADT, arm-eh, ast-experimental, enum, forall-pointer-decay, jacob/cs343-translation, master, new-ast-unique-expr, pthread-emulation, qualifiedEnum, stuck-waitfor-destruct

Children:

2b4daf2, 64aeca0

Parents:

3c64c668 (diff), eef8dfb (diff)
Note: this is a merge changeset, the changes displayed below correspond to the merge itself.
Use the (diff) links above to see all the changes relative to each parent.

Message:

Merge branch 'master' into park_unpark

File:

• doc/proposals/vtable.md (modified) (3 diffs)

doc/proposals/vtable.md

@@ -237 +237 @@
 default is provided or not, the second syntax can be used to pick a
 parameter on instantiation.
+
+### Extension: Object Access
+This requires that the resolution scope (see below) is at the type level or
+has explicate points with names. These are the tables and table names used
+here.
+
+The system already knows where to find the virtual table and the object. If
+the tables have particular identities, or on the user side names, then it is
+meaningful to check if a binding virtual table is the same* as another. The
+main use of this is virtual table declarations also give the type they bind
+and if a binding table matches a known table then the underlyind object in the
+trait object must be of that type.
+
+* By identity, by value would work and in some senses be more flexiable. But
+  it would be slower and refering to further away functions would be harder.
+
+This gives one of the main new features of the hierarchical use of virtual
+tables (see below); the ability to recover the underlying object. Or a pointer
+of the approprate type it which both reflects the implementation and gives a
+convenent way to encode the boolean/conditional aspect of the operation which
+is that a different virtual table might be in use.
+
+There are two general ways to reperent this; a cast or a field access. The
+cast is traditional and would definitely fit if a single pointer repersents
+a trait object with the virtual table as part of the object. However for a
+double pointer field access might be more approprate. By this system though
+it is not the type that is used as the identifier but the virtual table. If
+there is one table per type than it becomes equivilant again. Otherwise the
+table has to be used as the identifier and the type is just a result of that
+which seems important for syntax.
 
 Hierarchy
@@ -482 +512 @@
 possibly like the one used to create the assertion.
 
+### Extension: Associated Types Use
+If the `associated_types.md` proposal is accepted the following trait could
+be added:
+
+    trait is_virtual(dtype T) {
+        dtype table;
+        // An example assertion:
+        const table & get_virtual_table(T &);
+    }
+
+There may be more assertions but there has to be at least one way to find
+the (possibly default) virtual table. It is required to construct instances
+of the type.
+
+Without the assotiated type it would look like this:
+
+    trait is_virtual(dtype T, dtype table) {
+        const table & get_virtual_table(T &);
+    }
+
+Which is just a little bit longer to use but becomes more problematic if the
+user has to explicately provide the table's name as it doesn't really have its
+own type name. If it does it is probably mangled.
+
 ### Virtual Tables as Types
 Here we consider encoding plus the implementation of functions on it to be a
@@ -560 +614 @@
 be used in only some of the declarations.
 
-    trait combiner fee = (summation_instance, sum);
+    trait combiner fee = {summation_instance, sum};
     trait combiner foe = summation_instance;