1.1 --- a/docs/structures.txt Sun Aug 24 19:20:45 2008 +0200
1.2 +++ b/docs/structures.txt Mon Aug 25 02:04:10 2008 +0200
1.3 @@ -161,12 +161,12 @@
1.4
1.5 A suitable structure layout might be something like this:
1.6
1.7 - Identifier Address Details Type Object ...
1.8 + Identifier Identifier Address Details Type Object ...
1.9
1.10 - 0 1 2 3 4 5
1.11 - classcode invocation invocation __class__ attribute ...
1.12 - reference #args, reference reference
1.13 - #defaults
1.14 + 0 1 2 3 4 5 6
1.15 + classcode attrcode invocation invocation __class__ attribute ...
1.16 + reference #args, reference reference
1.17 + #defaults
1.18
1.19 Here, the classcode refers to the attribute lookup table for the object. Since
1.20 classes and instances share the same classcode, they might resemble the
1.21 @@ -174,17 +174,17 @@
1.22
1.23 Class C:
1.24
1.25 - 0 1 2 3 4 5
1.26 - code for C __new__ __new__ class type attribute ...
1.27 - reference #args, reference reference
1.28 - #defaults
1.29 + 0 1 2 3 4 5 6
1.30 + code for C attrcode __new__ __new__ class type attribute ...
1.31 + for C reference #args, reference reference
1.32 + #defaults
1.33
1.34 Instance of C:
1.35
1.36 - 0 1 2 3 4 5
1.37 - code for C C.__call__ C.__call__ class C attribute ...
1.38 - reference #args, reference reference
1.39 - (if exists) #defaults
1.40 + 0 1 2 3 4 5 6
1.41 + code for C attrcode C.__call__ C.__call__ class C attribute ...
1.42 + for C reference #args, reference reference
1.43 + (if exists) #defaults
1.44
1.45 The __new__ reference would lead to code consisting of the following
1.46 instructions:
1.47 @@ -200,10 +200,10 @@
1.48
1.49 Function f:
1.50
1.51 - 0 1 2 3 4 5
1.52 - code for code code class attribute ...
1.53 - function reference #args, function (default)
1.54 - #defaults reference reference
1.55 + 0 1 2 3 4 5 6
1.56 + code for attrcode code code class attribute ...
1.57 + function for reference #args, function (default)
1.58 + function #defaults reference reference
1.59
1.60 Here, the code reference would lead to code for the function. Note that the
1.61 function locals are completely distinct from this structure and are not
1.62 @@ -214,10 +214,10 @@
1.63
1.64 Module m:
1.65
1.66 - 0 1 2 3 4 5
1.67 - code for m (unused) (unused) module type attribute ...
1.68 - reference (global)
1.69 - reference
1.70 + 0 1 2 3 4 5 6
1.71 + code for m attrcode (unused) (unused) module type attribute ...
1.72 + for m reference (global)
1.73 + reference
1.74
1.75 Both classes and modules have code in their definitions, but this would be
1.76 generated in order and not referenced externally.
1.77 @@ -257,3 +257,18 @@
1.78 Where accesses can be determined ahead of time (as discussed in the
1.79 optimisations section), the above algorithm may not necessarily be employed in
1.80 the generated code for some accesses.
1.81 +
1.82 +Instance/Class Compatibility
1.83 +----------------------------
1.84 +
1.85 +Although it would be possible to have a data structure mapping classes to
1.86 +compatible classes, which in the case of context (or self argument)
1.87 +suitability in invocations would involve a mapping from a class to itself plus
1.88 +its descendants, the need to retain the key to such a data structure for each
1.89 +class might introduce a noticeable overhead. Such a structure would
1.90 +effectively be a matrix with each dimension indexed using the same sequence of
1.91 +codes for each of the classes in a program.
1.92 +
1.93 +An alternative might be to insert descendants as special attributes into the
1.94 +object/attribute lookup table. This would also require an extra key to be
1.95 +retained, since each class would have its own attribute code.
