1.1 --- a/docs/structures.txt Mon Apr 06 01:57:40 2009 +0200
1.2 +++ /dev/null Thu Jan 01 00:00:00 1970 +0000
1.3 @@ -1,116 +0,0 @@
1.4 -Data Structures
1.5 -===============
1.6 -
1.7 -The __class__ Attribute
1.8 ------------------------
1.9 -
1.10 -All objects support the __class__ attribute:
1.11 -
1.12 -Class: refers to the type class (type.__class__ also refers to the type class)
1.13 -Function: refers to the function class
1.14 -Instance: refers to the class instantiated to make the object
1.15 -
1.16 -Invocation
1.17 -----------
1.18 -
1.19 -The following actions need to be supported:
1.20 -
1.21 -Class: create instance, call __init__ with instance, return object
1.22 -Function: call function body, return result
1.23 -Instance: call __call__ method, return result
1.24 -
1.25 -Structure Layout
1.26 -----------------
1.27 -
1.28 -The __new__ reference would lead to code consisting of the following
1.29 -instructions:
1.30 -
1.31 - create instance for C
1.32 - call C.__init__(instance, ...)
1.33 - return instance
1.34 -
1.35 -If C has a __call__ attribute, the invocation "slot" of C instances would
1.36 -refer to the same thing as C.__call__. This "slot" has to be prepared when
1.37 -creating instances, either by modifying the sequence of instructions used in,
1.38 -amongst other places, the instantiator function, or by generating a template
1.39 -instance whose details are copied when new instances are created.
1.40 -
1.41 -For functions, the same general layout applies:
1.42 -
1.43 -Function f:
1.44 -
1.45 - 0 1 2 3 4 5 6
1.46 - code for attrcode code code class attribute ...
1.47 - function for reference #args, function (default)
1.48 - function defaults reference reference
1.49 - reference
1.50 -
1.51 -Here, the code reference would lead to code for the function. Note that the
1.52 -function locals are completely distinct from this structure and are not
1.53 -comparable to attributes. Instead, attributes are reserved for default
1.54 -parameter values.
1.55 -
1.56 -For modules, there is no meaningful invocation reference:
1.57 -
1.58 -Module m:
1.59 -
1.60 - 0 1 2 3 4 5 6
1.61 - code for m attrcode (unused) (unused) module type attribute ...
1.62 - for m reference (global)
1.63 - reference
1.64 -
1.65 -Both classes and modules have code in their definitions, but this would be
1.66 -generated in order and not referenced externally.
1.67 -
1.68 -Invocation Operation
1.69 ---------------------
1.70 -
1.71 -Consequently, regardless of the object an invocation is always done as
1.72 -follows:
1.73 -
1.74 - get invocation reference (at object+1)
1.75 - jump to reference
1.76 -
1.77 -Additional preparation is necessary before the above code: positional
1.78 -arguments must be saved to the parameter stack, and keyword arguments must be
1.79 -resolved and saved to the appropriate position in the parameter stack.
1.80 -
1.81 -Attribute Operations
1.82 ---------------------
1.83 -
1.84 -Attribute access needs to go through the attribute lookup table. Some
1.85 -optimisations are possible and are described in the appropriate section.
1.86 -
1.87 -One important aspect of attribute access is the appropriate setting of the
1.88 -context in the acquired attribute value. From the table describing the
1.89 -acquisition of values, it is clear that the principal exception is that where
1.90 -a class-originating attribute is accessed on an instance. Consequently, the
1.91 -following algorithm could be employed once an attribute has been located:
1.92 -
1.93 - 1. If the attribute's context is a special value, indicating that it should
1.94 - be replaced upon instance access, then proceed to the next step;
1.95 - otherwise, acquire both the context and the object as they are.
1.96 -
1.97 - 2. If the accessor is an instance, use that as the value's context, acquiring
1.98 - only the object from the attribute.
1.99 -
1.100 -Where accesses can be determined ahead of time (as discussed in the
1.101 -optimisations section), the above algorithm may not necessarily be employed in
1.102 -the generated code for some accesses.
1.103 -
1.104 -Instance/Class Compatibility
1.105 -----------------------------
1.106 -
1.107 -Although it would be possible to have a data structure mapping classes to
1.108 -compatible classes, which in the case of context (or self argument)
1.109 -suitability in invocations would involve a mapping from a class to itself plus
1.110 -its descendants, the need to retain the key to such a data structure for each
1.111 -class might introduce a noticeable overhead. Such a structure would
1.112 -effectively be a matrix with each dimension indexed using the same sequence of
1.113 -codes for each of the classes in a program.
1.114 -
1.115 -The current solution is to insert descendants as special attributes into the
1.116 -object/attribute lookup table. This requires an extra key to be retained,
1.117 -since each class must provide its own attribute code such that upon an
1.118 -instance/class compatibility test, the code may be obtained and used in the
1.119 -object table.