Index: doc/proposals/virtual.txt =================================================================== --- doc/proposals/virtual.txt (revision c72f9fdda3f7c30ea9be86498e52e5e155eaf6dc) +++ doc/proposals/virtual.txt (revision e1e4aa908baef01e52649504aa76f0d56da9b012) @@ -66,5 +66,5 @@ The keyword trait is optional (by the same rules as the struct keyword). This -is not currently suported in CFA and the lookup is not possible to implement +is not currently supported in CFA and the lookup is not possible to implement statically. Therefore we need to add a new feature to handle having dynamic lookups like this. @@ -75,5 +75,5 @@ For instance specifying that the drawable trait reference looks up the type -of the first argument to find the implemenation would be : +of the first argument to find the implementation would be : trait drawable(otype T) { @@ -84,10 +84,10 @@ trait and single generic parameter on the function). In more complex cases it would have to be explicitly given, or a strong convention would have to be -enforced (e.g. implementation of trait functions is always drawn from the +enforced (e.g. implementation of trait functions is always drawn from the first polymorphic parameter). 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 implemenation. Hence a trait reference becomes a kind of +underlying type implementation. Hence a trait reference becomes a kind of abstract type, cannot be directly instantiated but can still be used. @@ -100,5 +100,5 @@ Extension: Multi-parameter Virtual Traits: -This implementation can be extented to traits with multiple parameters if +This implementation can be extended to traits with multiple parameters if one is called out as being the virtual trait. For example : @@ -122,5 +122,5 @@ To allow down casting strict virtual requires that all traits and structures -involved be orginized into a tree. Each trait or struct must have a unique +involved be organized into a tree. Each trait or struct must have a unique position on this tree (no multiple inheritance). @@ -148,8 +148,8 @@ This gives us an important extra feature, runtime checking of the parent-child relationship with a C++ dynamic_cast like operation. Allowing checked -convertions from trait references to more particular references, which works +conversions from trait references to more particular references, which works if the underlying type is, or is a child of, the new trait type. -Extention: Multiple Parents +Extension: Multiple Parents Although each trait/struct must have a unique position on each tree, it could @@ -161,18 +161,18 @@ The restriction being, the parents must come from different trees. This object (and all of its children) can be cast to either tree. This is handled -by generating a seperate vtable for each tree the structure is in. - -Extention: Multi-parameter Strict Virtual - -If a trait has multiple parameters than one must be called out to be the one -we generate seperate vtables for, as in : +by generating a separate vtable for each tree the structure is in. + +Extension: Multi-parameter Strict Virtual + +If a trait has multiple parameters then one must be called out to be the one +we generate separate vtables for, as in : trait example(otype T, otype U) virtual(T) ... -This can generate a seperate vtable for each U for which all the T+U -implementations are provided. These are then seperate nodes in the tree (or -the root of different trees) as if each was created individually. Providing a -single unique instance of these nodes would be the most difficult aspect of -this extension, possibly intractable, though with sufficient hoisting and +This can generate a separate vtable for each U for which all the T+U +implementations are provided. These are then separate nodes in the tree (or +the root of different trees) as if each was created individually. Providing a +single unique instance of these nodes would be the most difficult aspect of +this extension, possibly intractable, though with sufficient hoisting and link-once duplication it may be possible. @@ -188,8 +188,8 @@ }; -Extention: Structural Inheritance +Extension: Structural Inheritance Currently traits must be the internal nodes and structs the leaf nodes. -Structs could be made internal nodes as well, in which case the child structs +Structs could be made internal nodes as well, in which case the child structs would likely structurally inherit the fields of their parents. @@ -201,6 +201,6 @@ 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 reqired). For strict virtual this must happen at the -global scope and forbiding static functions, to ensure that a single unique +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. @@ -209,5 +209,5 @@ 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 implicately. +already follow implicitly. Most vtables should be stored statically, the only exception being some of @@ -222,9 +222,9 @@ stored along side it. -This allows for compatability with existing structures (such as those imported +This allows for compatibility with existing structures (such as those imported from C) and is the default storage method unless a different one is given. The other is by inlining the vtable pointer as "intrusive vtables". This adds -a field to the structure to the vtable. The trait reference than has a single +a field to the structure to the vtable. The trait reference then has a single pointer to this field, the vtable includes an offset to find the beginning of the structure again. @@ -233,5 +233,5 @@ trait the vtable pointer in the trait reference can then become a single pointer to the vtable field and use that to recover the original object -pointer as well as retrive all operations. +pointer as well as retrieve all operations. trait drawable(otype T) { @@ -248,5 +248,5 @@ (although they still must be called specially). The vtable field may just be an opaque block of memory or it may allow user access to the vtable. If so -than there should be some way to retrive the type of the vtable, which will be +then there should be some way to retrieve the type of the vtable, which will be autogenerated and often unique.