Reattachment - Revision history

Alexander Kogtenkov: /* Unification of feature signature */ Added an example to demonstrate that feature signature may not be known in advance

2007-03-30T14:54:07Z

‎Unification of feature signature: Added an example to demonstrate that feature signature may not be known in advance

Alexander Kogtenkov: /* Reattachment of generic derivations in classic */ Divided the text into several sections

2007-03-30T14:04:00Z

‎Reattachment of generic derivations in classic: Divided the text into several sections

Alexander Kogtenkov: /* Reattachment of generic derivations in classic */ Cosmetics

2007-03-27T11:48:58Z

‎Reattachment of generic derivations in classic: Cosmetics

Seilerm: typo fixed

2007-03-26T20:41:02Z

typo fixed

Alexander Kogtenkov: Added an initial version with the description of implementation on classic

2007-03-26T14:54:38Z

Added an initial version with the description of implementation on classic

New page

[[Category: Compiler]]
[[Category: ECMA]]
See also: [[Object_Layout]], [[Dynamic_Binding]]
== Introduction ==
Conformance of expanded types to (particular) reference types implies that objects of generically derived types with expanded parameters can be attached to generically derived types with reference parameters (e.g., <e>ARRAY [INTEGER]</e> can be attached to <e>ARRAY [ANY]</e>).
All features in a generic derivation with an expanded parameter that involve this generic parameter should be able to handle the case when they are called on a target where this generic parameter is reference, i.e. they should be able to take reference arguments and return reference result.
== Reattachment of generic derivations in classic ==
# In addition to the "normal" version of the method generated for a particular feature, a new stub can be generated so that its arguments/result types match those of the generic derivation with reference generic parameters. In order to avoid additional pressure on garbage collector, the values passed to/from the generated methods can be embedded in an EIF_UNION structure that allows to pass objects of basic and reference types "as is", while objects of user-defined expanded type still need to be "boxed" and kept in the heap.
# The feature <e>{ROUT_TABLE}.is_polymorphic</e> has to be modified so that it allows for different generic derivatins to share the same table, because now it becomes possible to reattach generic derivations with expanded parameters to the generic derivations with reference parameters. Though not all the reattachments are possible (e.g., no reattachment is possible between the types <e>ARRAY [INTEGER]</e> and <e>ARRAY [BOOLEAN]</e>), it's too complicated and/or resource consuming to create the tables for every generic derivation and types that conform to it.
# Attributes that are declared of a formal generic type (or as of type, anchored to a feature of a formal generic type) have to be accessed as functions so that they can be safely access from the generic derivations with reference parameters. This involves two changes in code generation:
## Promotion of <e>ATTRIBUTE_B</e> to <e>FEATURE_B</e> if an attribute type is (directly or indirectly) a formal generic.
## Generation of an accessor for the attribute by setting the field <e>generated_in</e>.

@@ Line 9: / Line 9: @@
 The feature <e>{ROUT_TABLE}.is_polymorphic</e> has to be modified so that it allows for different generic derivations to share the same table, because now it becomes possible to reattach generic derivations with expanded parameters to the generic derivations with reference parameters. Though not all the reattachments are possible (e.g., no reattachment is possible between the types <e>ARRAY [INTEGER]</e> and <e>ARRAY [BOOLEAN]</e>), it's too complicated and/or resource consuming to create the tables for every generic derivation and types that conform to it.
 === Unification of feature signature ===
-In addition to the "normal" version of the method generated for a particular feature, a new stub can be generated so that its arguments/result types match those of the generic derivation with reference generic parameters. In order to avoid additional pressure on garbage collector, the values passed to/from the generated methods can be embedded in an EIF_UNION structure that allows to pass objects of basic and reference types "as is", while objects of user-defined expanded type still need to be "boxed" and kept in the heap.
+In addition to the "normal" version of the method generated for a particular feature, a new stub can be generated so that its arguments/result types match those of the generic derivation with reference generic parameters. In order to avoid additional pressure on garbage collector, the values passed to/from the generated methods can be embedded in an <c>EIF_UNION</c> structure that allows to pass objects of basic and reference types "as is", while objects of user-defined expanded type still need to be "boxed" and kept in the heap.
 === Access to attributes ===
 Attributes that are declared of a formal generic type (or as of type, anchored to a feature of a formal generic type) have to be accessed as functions so that they can be safely accessed from the generic derivations with reference parameters. This involves two changes in code generation:
 # Promotion of <e>ATTRIBUTE_B</e> to <e>FEATURE_B</e> if an attribute type is (directly or indirectly) a formal generic.
 # Generation of an accessor for the attribute by setting the field <e>generated_in</e>.

@@ Line 6: / Line 6: @@
 All features in a generic derivation with an expanded parameter that involve this generic parameter should be able to handle the case when they are called on a target where this generic parameter is reference, i.e. they should be able to take reference arguments and return reference result.
 == Reattachment of generic derivations in classic ==
-# '''Dynamic dispatch'''.The feature <e>{ROUT_TABLE}.is_polymorphic</e> has to be modified so that it allows for different generic derivations to share the same table, because now it becomes possible to reattach generic derivations with expanded parameters to the generic derivations with reference parameters. Though not all the reattachments are possible (e.g., no reattachment is possible between the types <e>ARRAY [INTEGER]</e> and <e>ARRAY [BOOLEAN]</e>), it's too complicated and/or resource consuming to create the tables for every generic derivation and types that conform to it.
+=== Dynamic dispatch ===
-# '''Unification of feature signature'''. In addition to the "normal" version of the method generated for a particular feature, a new stub can be generated so that its arguments/result types match those of the generic derivation with reference generic parameters. In order to avoid additional pressure on garbage collector, the values passed to/from the generated methods can be embedded in an EIF_UNION structure that allows to pass objects of basic and reference types "as is", while objects of user-defined expanded type still need to be "boxed" and kept in the heap.
+The feature <e>{ROUT_TABLE}.is_polymorphic</e> has to be modified so that it allows for different generic derivations to share the same table, because now it becomes possible to reattach generic derivations with expanded parameters to the generic derivations with reference parameters. Though not all the reattachments are possible (e.g., no reattachment is possible between the types <e>ARRAY [INTEGER]</e> and <e>ARRAY [BOOLEAN]</e>), it's too complicated and/or resource consuming to create the tables for every generic derivation and types that conform to it.
-# '''Access to attributes'''. Attributes that are declared of a formal generic type (or as of type, anchored to a feature of a formal generic type) have to be accessed as functions so that they can be safely accessed from the generic derivations with reference parameters. This involves two changes in code generation:
+=== Unification of feature signature ===
-## Promotion of <e>ATTRIBUTE_B</e> to <e>FEATURE_B</e> if an attribute type is (directly or indirectly) a formal generic.
+In addition to the "normal" version of the method generated for a particular feature, a new stub can be generated so that its arguments/result types match those of the generic derivation with reference generic parameters. In order to avoid additional pressure on garbage collector, the values passed to/from the generated methods can be embedded in an EIF_UNION structure that allows to pass objects of basic and reference types "as is", while objects of user-defined expanded type still need to be "boxed" and kept in the heap.
-## Generation of an accessor for the attribute by setting the field <e>generated_in</e>.
+=== Access to attributes ===

@@ Line 7: / Line 7: @@
 == Reattachment of generic derivations in classic ==
 # In addition to the "normal" version of the method generated for a particular feature, a new stub can be generated so that its arguments/result types match those of the generic derivation with reference generic parameters. In order to avoid additional pressure on garbage collector, the values passed to/from the generated methods can be embedded in an EIF_UNION structure that allows to pass objects of basic and reference types "as is", while objects of user-defined expanded type still need to be "boxed" and kept in the heap.
-# The feature <e>{ROUT_TABLE}.is_polymorphic</e> has to be modified so that it allows for different generic derivatins to share the same table, because now it becomes possible to reattach generic derivations with expanded parameters to the generic derivations with reference parameters. Though not all the reattachments are possible (e.g., no reattachment is possible between the types <e>ARRAY [INTEGER]</e> and <e>ARRAY [BOOLEAN]</e>), it's too complicated and/or resource consuming to create the tables for every generic derivation and types that conform to it.
+# The feature <e>{ROUT_TABLE}.is_polymorphic</e> has to be modified so that it allows for different generic derivations to share the same table, because now it becomes possible to reattach generic derivations with expanded parameters to the generic derivations with reference parameters. Though not all the reattachments are possible (e.g., no reattachment is possible between the types <e>ARRAY [INTEGER]</e> and <e>ARRAY [BOOLEAN]</e>), it's too complicated and/or resource consuming to create the tables for every generic derivation and types that conform to it.
 # Attributes that are declared of a formal generic type (or as of type, anchored to a feature of a formal generic type) have to be accessed as functions so that they can be safely access from the generic derivations with reference parameters. This involves two changes in code generation:
 ## Promotion of <e>ATTRIBUTE_B</e> to <e>FEATURE_B</e> if an attribute type is (directly or indirectly) a formal generic.
 ## Generation of an accessor for the attribute by setting the field <e>generated_in</e>.