Changeset da81e1d0 for doc/proposals

Timestamp:

Nov 18, 2016, 1:47:00 PM (8 years ago)

Author:

Aaron Moss <a3moss@…>

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:

ba5131d

Parents:

5a0735ac

Message:

Added notes on vtable binding and bikeshedding to virtual proposal

File:

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

doc/proposals/virtual.txt

@@ -106 +106 @@
 would have many ambiguities if it did support multiple virtual parameter.
 
+It is worth noting that the function pointers in these vtables are bound at object construction, rather than 
+function call-site, as in Cforall's existing polymorphic functions. As such, it is possible that two objects 
+with the same static type would have a different vtable (consider what happens if draw(line*) is overridden 
+between the definitions of two line objects). Given that the virtual drawable* erases static types though, 
+this should not be confusing in practice. A more distressing possibility is that of creating an object that 
+outlives the scope of one of the functions in its vtable. This is certainly a possible bug, but it is of a 
+type that C programmers are familiar with, and should be able to avoid by the usual methods.
+
 Extensibility.
 
@@ -145 +153 @@
 
 These behave exactly as the previous example but all the forwarding routines are automatically generated.
+
+Bikeshedding.
+
+It may be desirable to add fewer new keywords than discussed in this proposal; it is possible that "virtual" 
+could replace both "vtable" and "vptr" above with unambiguous contextual meaning. However, for purposes of 
+clarity in the design discussion it is beneficial to keep the keywords for separate concepts distinct.
+