Author: allison Date: Mon Feb 5 21:42:00 2007 New Revision: 16905 Modified: trunk/docs/pdds/draft/pddXX_cstruct.pod
Log: Fix a few typos in the CStruct proposal. Modified: trunk/docs/pdds/draft/pddXX_cstruct.pod ============================================================================== --- trunk/docs/pdds/draft/pddXX_cstruct.pod (original) +++ trunk/docs/pdds/draft/pddXX_cstruct.pod Mon Feb 5 21:42:00 2007 @@ -160,7 +160,7 @@ Access to array elements automatically does bounds checking. -=head2 Possible future extemsios +=head2 Possible future extensions cs = subclass 'CStruct', 'todo' addattribute(s) foo_cs, <<'DEF' @@ -200,7 +200,7 @@ communicate all information "upstairs" to the HLL users. But it's not HLL usage only, parrot itself is already suffering from -lack of abstraction at PMC level. +a lack of abstraction at the PMC level. =head2 Inheritance @@ -218,7 +218,7 @@ totally fine) it's just the lack of usability of parrot (when it comes to native structures (or PMCs)). -All these experiments to use a C structures or a PMC as base class are +All these experiments to use a C structure or a PMC as base class are ending with a C<has> relationship instead of the natural C<isa>. Any useful OO-ish abstraction is lost and is leading to clumsy code, and - no - implementing interfaces/traits/mixins can't help here, as @@ -270,7 +270,7 @@ equivalent syntax can be translated by the PMC compiler to achieve the same result. -This definition of the attributes of that PMC provides automagically +This definition of the attributes of that PMC automagically provides access to all the information stored in the PMC. All such access is currently hand-crafted in the F<complex.pmc>. Not only that this accessor code could be abandoned (and unified with common syntax),
