paul@15 | 1 | Namespace Definition
|
paul@15 | 2 | ====================
|
paul@15 | 3 |
|
paul@15 | 4 | Module attributes are defined either at the module level or by global
|
paul@15 | 5 | statements.
|
paul@15 | 6 |
|
paul@15 | 7 | Class attributes are defined only within class statements.
|
paul@15 | 8 |
|
paul@15 | 9 | Instance attributes are defined only by assignments to attributes of self
|
paul@15 | 10 | within __init__ methods.
|
paul@15 | 11 |
|
paul@42 | 12 | Potential Restrictions
|
paul@42 | 13 | ----------------------
|
paul@42 | 14 |
|
paul@42 | 15 | Names of classes and functions could be restricted to only refer to those
|
paul@42 | 16 | objects within the same namespace. If redefinition were to occur, or if
|
paul@42 | 17 | multiple possibilities were present, these restrictions could be moderated as
|
paul@42 | 18 | follows:
|
paul@42 | 19 |
|
paul@42 | 20 | * Classes assigned to the same name could provide the union of their
|
paul@42 | 21 | attributes. This would, however, cause a potential collision of attribute
|
paul@42 | 22 | definitions such as methods.
|
paul@42 | 23 |
|
paul@42 | 24 | * Functions, if they share compatible signatures, could share parameter list
|
paul@42 | 25 | definitions.
|
paul@42 | 26 |
|
paul@11 | 27 | Data Structures
|
paul@11 | 28 | ===============
|
paul@11 | 29 |
|
paul@45 | 30 | The fundamental "value type" is a pair of references: one pointing to the
|
paul@45 | 31 | referenced object represented by the interchangeable value; one referring to
|
paul@45 | 32 | the context of the referenced object, typically the object through which the
|
paul@82 | 33 | referenced object was acquired as an attribute.
|
paul@45 | 34 |
|
paul@45 | 35 | Value Layout
|
paul@45 | 36 | ------------
|
paul@45 | 37 |
|
paul@45 | 38 | 0 1
|
paul@45 | 39 | object context
|
paul@45 | 40 | reference reference
|
paul@45 | 41 |
|
paul@52 | 42 | Acquiring Values
|
paul@52 | 43 | ----------------
|
paul@52 | 44 |
|
paul@52 | 45 | Values are acquired through name lookups and attribute access, yielding
|
paul@52 | 46 | the appropriate object reference together with a context reference as
|
paul@52 | 47 | indicated in the following table:
|
paul@52 | 48 |
|
paul@52 | 49 | Type of Access Context Notes
|
paul@52 | 50 | -------------- ------- -----
|
paul@52 | 51 |
|
paul@52 | 52 | Local name Preserved Functions provide no context
|
paul@52 | 53 |
|
paul@52 | 54 | Global name Preserved Modules provide no context
|
paul@52 | 55 |
|
paul@87 | 56 | Class-originating Accessor Class accessor preserves the stored
|
paul@87 | 57 | attribute -or- context; instance accessor overrides
|
paul@87 | 58 | Preserved the stored context if it is null or
|
paul@87 | 59 | belongs to the instance's class
|
paul@87 | 60 | hierarchy
|
paul@52 | 61 |
|
paul@52 | 62 | Instance-originating Preserved Methods retain their original context
|
paul@52 | 63 | attribute
|
paul@52 | 64 |
|
paul@53 | 65 | There may be some scope for simplifying the above, to the detriment of Python
|
paul@52 | 66 | compatibility, since the unbound vs. bound methods situation can be confusing.
|
paul@52 | 67 |
|
paul@86 | 68 | Manipulating Values
|
paul@86 | 69 | -------------------
|
paul@86 | 70 |
|
paul@86 | 71 | According to the table describing value acquisition, different instructions
|
paul@86 | 72 | must implement different operations when acquiring values:
|
paul@86 | 73 |
|
paul@86 | 74 | Instruction Purpose Context Operations
|
paul@86 | 75 | ----------- ------- ------------------
|
paul@86 | 76 |
|
paul@86 | 77 | LoadConst Load class, function, Combine null context with loaded
|
paul@86 | 78 | module, constant object
|
paul@86 | 79 |
|
paul@86 | 80 | LoadAddress Load attribute from Classes, functions and modules
|
paul@86 | 81 | known object stored as cause the loaded attribute to be
|
paul@87 | 82 | an attribute retrieved unchanged; whereas
|
paul@87 | 83 | constants (representing instances)
|
paul@87 | 84 | cause the constant to override the
|
paul@87 | 85 | attribute's own context (since all
|
paul@87 | 86 | attributes should belong to the
|
paul@87 | 87 | constant's class hierarchy)
|
paul@86 | 88 |
|
paul@87 | 89 | LoadAttr Load attribute from Attributes with null contexts or
|
paul@87 | 90 | instance stored as an contexts compatible with the
|
paul@87 | 91 | attribute instance cause loaded attributes
|
paul@87 | 92 | to combine the instance as context
|
paul@87 | 93 | with the object from the
|
paul@87 | 94 | attribute; other attributes have
|
paul@87 | 95 | their context preserved
|
paul@86 | 96 |
|
paul@86 | 97 | LoadAttrIndex Load attribute from Classes, functions and modules as
|
paul@86 | 98 | unknown object stored the unknown object accessor cause
|
paul@86 | 99 | as an attribute the loaded attribute to be
|
paul@87 | 100 | retrieved unchanged; whereas
|
paul@87 | 101 | instances cause the LoadAttr rules
|
paul@87 | 102 | to apply
|
paul@86 | 103 |
|
paul@87 | 104 | Consequently, a certain amount of run-time testing is required for both
|
paul@87 | 105 | LoadAttr and LoadAttrIndex.
|
paul@86 | 106 |
|
paul@45 | 107 | Objects
|
paul@45 | 108 | -------
|
paul@45 | 109 |
|
paul@11 | 110 | Since classes, functions and instances are all "objects", each must support
|
paul@11 | 111 | certain features and operations in the same way.
|
paul@11 | 112 |
|
paul@11 | 113 | The __class__ Attribute
|
paul@11 | 114 | -----------------------
|
paul@11 | 115 |
|
paul@11 | 116 | All objects support the __class__ attribute:
|
paul@11 | 117 |
|
paul@11 | 118 | Class: refers to the type class (type.__class__ also refers to the type class)
|
paul@11 | 119 | Function: refers to the function class
|
paul@11 | 120 | Instance: refers to the class instantiated to make the object
|
paul@11 | 121 |
|
paul@11 | 122 | Invocation
|
paul@11 | 123 | ----------
|
paul@11 | 124 |
|
paul@11 | 125 | The following actions need to be supported:
|
paul@11 | 126 |
|
paul@11 | 127 | Class: create instance, call __init__ with instance, return object
|
paul@11 | 128 | Function: call function body, return result
|
paul@11 | 129 | Instance: call __call__ method, return result
|
paul@11 | 130 |
|
paul@11 | 131 | Structure Layout
|
paul@11 | 132 | ----------------
|
paul@11 | 133 |
|
paul@11 | 134 | A suitable structure layout might be something like this:
|
paul@11 | 135 |
|
paul@59 | 136 | Identifier Address Type Object ...
|
paul@59 | 137 |
|
paul@11 | 138 | 0 1 2 3 4
|
paul@11 | 139 | classcode invocation __class__ attribute ...
|
paul@11 | 140 | reference reference reference
|
paul@11 | 141 |
|
paul@11 | 142 | Here, the classcode refers to the attribute lookup table for the object. Since
|
paul@11 | 143 | classes and instances share the same classcode, they might resemble the
|
paul@11 | 144 | following:
|
paul@11 | 145 |
|
paul@11 | 146 | Class C:
|
paul@11 | 147 |
|
paul@11 | 148 | 0 1 2 3 4
|
paul@11 | 149 | code for C __new__ class type attribute ...
|
paul@11 | 150 | reference reference reference
|
paul@11 | 151 |
|
paul@11 | 152 | Instance of C:
|
paul@11 | 153 |
|
paul@11 | 154 | 0 1 2 3 4
|
paul@11 | 155 | code for C C.__call__ class C attribute ...
|
paul@11 | 156 | reference reference reference
|
paul@11 | 157 | (if exists)
|
paul@11 | 158 |
|
paul@11 | 159 | The __new__ reference would lead to code consisting of the following
|
paul@11 | 160 | instructions:
|
paul@11 | 161 |
|
paul@11 | 162 | create instance for C
|
paul@11 | 163 | call C.__init__(instance, ...)
|
paul@11 | 164 | return instance
|
paul@11 | 165 |
|
paul@11 | 166 | If C has a __call__ attribute, the invocation "slot" of C instances would
|
paul@11 | 167 | refer to the same thing as C.__call__.
|
paul@11 | 168 |
|
paul@11 | 169 | For functions, the same general layout applies:
|
paul@11 | 170 |
|
paul@11 | 171 | Function f:
|
paul@11 | 172 |
|
paul@11 | 173 | 0 1 2 3 4
|
paul@11 | 174 | code for code class attribute ...
|
paul@11 | 175 | function reference function reference
|
paul@11 | 176 | reference
|
paul@11 | 177 |
|
paul@37 | 178 | Here, the code reference would lead to code for the function. Note that the
|
paul@37 | 179 | function locals are completely distinct from this structure and are not
|
paul@37 | 180 | comparable to attributes.
|
paul@37 | 181 |
|
paul@38 | 182 | For modules, there is no meaningful invocation reference:
|
paul@37 | 183 |
|
paul@37 | 184 | Module m:
|
paul@37 | 185 |
|
paul@37 | 186 | 0 1 2 3 4
|
paul@38 | 187 | code for m (unused) module type attribute ...
|
paul@38 | 188 | reference (global)
|
paul@37 | 189 | reference
|
paul@11 | 190 |
|
paul@38 | 191 | Both classes and modules have code in their definitions, but this would be
|
paul@38 | 192 | generated in order and not referenced externally.
|
paul@38 | 193 |
|
paul@11 | 194 | Invocation Operation
|
paul@11 | 195 | --------------------
|
paul@11 | 196 |
|
paul@11 | 197 | Consequently, regardless of the object an invocation is always done as
|
paul@11 | 198 | follows:
|
paul@11 | 199 |
|
paul@11 | 200 | get invocation reference (at object+1)
|
paul@11 | 201 | jump to reference
|
paul@11 | 202 |
|
paul@11 | 203 | Additional preparation is necessary before the above code: positional
|
paul@11 | 204 | arguments must be saved to the parameter stack, and keyword arguments must be
|
paul@11 | 205 | resolved and saved to the appropriate position in the parameter stack.
|
paul@11 | 206 |
|
paul@11 | 207 | Attribute Operations
|
paul@11 | 208 | --------------------
|
paul@11 | 209 |
|
paul@53 | 210 | Attribute access needs to go through the attribute lookup table. Some
|
paul@53 | 211 | optimisations are possible and are described in the appropriate section.
|
paul@53 | 212 |
|
paul@53 | 213 | One important aspect of attribute access is the appropriate setting of the
|
paul@53 | 214 | context in the acquired attribute value. From the table describing the
|
paul@53 | 215 | acquisition of values, it is clear that the principal exception is that where
|
paul@53 | 216 | a class-originating attribute is accessed on an instance. Consequently, the
|
paul@53 | 217 | following algorithm could be employed once an attribute has been located:
|
paul@53 | 218 |
|
paul@53 | 219 | 1. If the attribute's context is a special value, indicating that it should
|
paul@53 | 220 | be replaced upon instance access, then proceed to the next step;
|
paul@53 | 221 | otherwise, acquire both the context and the object as they are.
|
paul@53 | 222 |
|
paul@53 | 223 | 2. If the accessor is an instance, use that as the value's context, acquiring
|
paul@53 | 224 | only the object from the attribute.
|
paul@53 | 225 |
|
paul@53 | 226 | Where accesses can be determined ahead of time (as discussed in the
|
paul@53 | 227 | optimisations section), the above algorithm may not necessarily be employed in
|
paul@53 | 228 | the generated code for some accesses.
|
paul@21 | 229 |
|
paul@21 | 230 | Instruction Evaluation Model
|
paul@21 | 231 | ============================
|
paul@21 | 232 |
|
paul@21 | 233 | Programs use a value stack where evaluated instructions may save their
|
paul@21 | 234 | results. A value stack pointer indicates the top of this stack. In addition, a
|
paul@21 | 235 | separate stack is used to record the invocation frames. All stack pointers
|
paul@21 | 236 | refer to the next address to be used by the stack, not the address of the
|
paul@21 | 237 | uppermost element.
|
paul@21 | 238 |
|
paul@21 | 239 | Frame Stack Value Stack
|
paul@21 | 240 | ----------- ----------- Address of Callable
|
paul@21 | 241 | -------------------
|
paul@21 | 242 | previous ...
|
paul@21 | 243 | current ------> callable -----> identifier
|
paul@21 | 244 | arg1 reference to code
|
paul@21 | 245 | arg2
|
paul@21 | 246 | arg3
|
paul@21 | 247 | local4
|
paul@21 | 248 | local5
|
paul@21 | 249 | ...
|
paul@21 | 250 |
|
paul@21 | 251 | Loading local names is a matter of performing frame-relative accesses to the
|
paul@21 | 252 | value stack.
|
paul@21 | 253 |
|
paul@21 | 254 | Invocations and Argument Evaluation
|
paul@21 | 255 | -----------------------------------
|
paul@21 | 256 |
|
paul@21 | 257 | When preparing for an invocation, the caller first sets the invocation frame
|
paul@21 | 258 | pointer. Then, positional arguments are added to the stack such that the first
|
paul@21 | 259 | argument positions are filled. A number of stack locations for the remaining
|
paul@21 | 260 | arguments specified in the program are then reserved. The names of keyword
|
paul@21 | 261 | arguments are used (in the form of table index values) to consult the
|
paul@21 | 262 | parameter table and to find the location in which such arguments are to be
|
paul@21 | 263 | stored.
|
paul@21 | 264 |
|
paul@21 | 265 | fn(a, b, d=1, e=2, c=3) -> fn(a, b, c, d, e)
|
paul@21 | 266 |
|
paul@21 | 267 | Value Stack
|
paul@21 | 268 | -----------
|
paul@21 | 269 |
|
paul@21 | 270 | ... ... ... ...
|
paul@21 | 271 | fn fn fn fn
|
paul@21 | 272 | a a a a
|
paul@21 | 273 | b b b b
|
paul@21 | 274 | ___ ___ ___ --> 3
|
paul@21 | 275 | ___ --> 1 1 | 1
|
paul@21 | 276 | ___ | ___ --> 2 | 2
|
paul@21 | 277 | 1 ----------- 2 ----------- 3 -----------
|
paul@21 | 278 |
|
paul@21 | 279 | Conceptually, the frame can be considered as a collection of attributes, as
|
paul@21 | 280 | seen in other kinds of structures:
|
paul@21 | 281 |
|
paul@21 | 282 | Frame for invocation of fn:
|
paul@21 | 283 |
|
paul@21 | 284 | 0 1 2 3 4 5
|
paul@21 | 285 | code a b c d e
|
paul@21 | 286 | reference
|
paul@21 | 287 |
|
paul@21 | 288 | However, where arguments are specified positionally, such "attributes" are not
|
paul@21 | 289 | set using a comparable approach to that employed with other structures.
|
paul@21 | 290 | Keyword arguments are set using an attribute-like mechanism, though, where the
|
paul@21 | 291 | position of each argument discovered using the parameter table.
|
paul@21 | 292 |
|
paul@67 | 293 | Where the target of the invocation is known, the above procedure can be
|
paul@67 | 294 | optimised slightly by attempting to add keyword argument values directly to
|
paul@67 | 295 | the stack:
|
paul@67 | 296 |
|
paul@67 | 297 | Value Stack
|
paul@67 | 298 | -----------
|
paul@67 | 299 |
|
paul@67 | 300 | ... ... ... ... ...
|
paul@67 | 301 | fn fn fn fn fn
|
paul@67 | 302 | a a a a a
|
paul@67 | 303 | b b b b b
|
paul@67 | 304 | ___ ___ ___ --> 3
|
paul@67 | 305 | 1 1 1 | 1
|
paul@67 | 306 | 2 1 | 2
|
paul@67 | 307 | 3 -----------
|
paul@67 | 308 |
|
paul@67 | 309 | (reserve for (add in-place) (add in-place) (evaluate) (store by
|
paul@67 | 310 | parameter c) index)
|
paul@67 | 311 |
|
paul@67 | 312 | Method Invocations
|
paul@67 | 313 | ------------------
|
paul@67 | 314 |
|
paul@45 | 315 | Method invocations incorporate an implicit first argument which is obtained
|
paul@45 | 316 | from the context of the method:
|
paul@45 | 317 |
|
paul@45 | 318 | method(a, b, d=1, e=2, c=3) -> method(self, a, b, c, d, e)
|
paul@45 | 319 |
|
paul@45 | 320 | Value Stack
|
paul@45 | 321 | -----------
|
paul@45 | 322 |
|
paul@45 | 323 | ...
|
paul@45 | 324 | method
|
paul@45 | 325 | context of method
|
paul@45 | 326 | a
|
paul@45 | 327 | b
|
paul@45 | 328 | 3
|
paul@45 | 329 | 1
|
paul@45 | 330 | 2
|
paul@45 | 331 |
|
paul@45 | 332 | Although it could be possible to permit any object to be provided as the first
|
paul@45 | 333 | argument, in order to optimise instance attribute access in methods, we should
|
paul@45 | 334 | seek to restrict the object type.
|
paul@45 | 335 |
|
paul@58 | 336 | Verifying Supplied Arguments
|
paul@58 | 337 | ----------------------------
|
paul@58 | 338 |
|
paul@58 | 339 | In order to ensure a correct invocation, it is also necessary to check the
|
paul@58 | 340 | number of supplied arguments. If the target of the invocation is known at
|
paul@58 | 341 | compile-time, no additional instructions need to be emitted; otherwise, the
|
paul@58 | 342 | generated code must test for the following situations:
|
paul@58 | 343 |
|
paul@58 | 344 | 1. That the number of supplied arguments is equal to the number of expected
|
paul@58 | 345 | parameters.
|
paul@58 | 346 |
|
paul@58 | 347 | 2. That no keyword argument overwrites an existing positional parameter.
|
paul@58 | 348 |
|
paul@66 | 349 | Default Arguments
|
paul@66 | 350 | -----------------
|
paul@66 | 351 |
|
paul@66 | 352 | Some arguments may have default values which are used if no value is provided
|
paul@66 | 353 | in an invocation. Such defaults are initialised when the function itself is
|
paul@66 | 354 | initialised, and are used to fill in any invocation frames that are known at
|
paul@66 | 355 | compile-time.
|
paul@66 | 356 |
|
paul@21 | 357 | Tuples, Frames and Allocation
|
paul@21 | 358 | -----------------------------
|
paul@21 | 359 |
|
paul@21 | 360 | Using the approach where arguments are treated like attributes in some kind of
|
paul@21 | 361 | structure, we could choose to allocate frames in places other than a stack.
|
paul@21 | 362 | This would produce something somewhat similar to a plain tuple object.
|
paul@23 | 363 |
|
paul@23 | 364 | Optimisations
|
paul@23 | 365 | =============
|
paul@23 | 366 |
|
paul@29 | 367 | Some optimisations around constant objects might be possible; these depend on
|
paul@29 | 368 | the following:
|
paul@29 | 369 |
|
paul@29 | 370 | * Reliable tracking of assignments: where assignment operations occur, the
|
paul@29 | 371 | target of the assignment should be determined if any hope of optimisation
|
paul@29 | 372 | is to be maintained. Where no guarantees can be made about the target of
|
paul@29 | 373 | an assignment, no assignment-related information should be written to
|
paul@29 | 374 | potential targets.
|
paul@29 | 375 |
|
paul@29 | 376 | * Objects acting as "containers" of attributes must be regarded as "safe":
|
paul@29 | 377 | where assignments are recorded as occurring on an attribute, it must be
|
paul@29 | 378 | guaranteed that no other unforeseen ways exist to assign to such
|
paul@29 | 379 | attributes.
|
paul@29 | 380 |
|
paul@29 | 381 | The discussion below presents certain rules which must be imposed to uphold
|
paul@29 | 382 | the above requirements.
|
paul@29 | 383 |
|
paul@30 | 384 | Safe Containers
|
paul@30 | 385 | ---------------
|
paul@28 | 386 |
|
paul@23 | 387 | Where attributes of modules, classes and instances are only set once and are
|
paul@23 | 388 | effectively constant, it should be possible to circumvent the attribute lookup
|
paul@28 | 389 | mechanism and to directly reference the attribute value. This technique may
|
paul@30 | 390 | only be considered applicable for the following "container" objects, subject
|
paul@30 | 391 | to the noted constraints:
|
paul@28 | 392 |
|
paul@30 | 393 | 1. For modules, "safety" is enforced by ensuring that assignments to module
|
paul@30 | 394 | attributes are only permitted within the module itself either at the
|
paul@30 | 395 | top-level or via names declared as globals. Thus, the following would not
|
paul@30 | 396 | be permitted:
|
paul@28 | 397 |
|
paul@28 | 398 | another_module.this_module.attr = value
|
paul@28 | 399 |
|
paul@29 | 400 | In the above, this_module is a reference to the current module.
|
paul@28 | 401 |
|
paul@30 | 402 | 2. For classes, "safety" is enforced by ensuring that assignments to class
|
paul@30 | 403 | attributes are only permitted within the class definition, outside
|
paul@30 | 404 | methods. This would mean that classes would be "sealed" at definition time
|
paul@30 | 405 | (like functions).
|
paul@28 | 406 |
|
paul@28 | 407 | Unlike the property of function locals that they may only sensibly be accessed
|
paul@28 | 408 | within the function in which they reside, these cases demand additional
|
paul@28 | 409 | controls or assumptions on or about access to the stored data. Meanwhile, it
|
paul@28 | 410 | would be difficult to detect eligible attributes on arbitrary instances due to
|
paul@28 | 411 | the need for some kind of type inference or abstract execution.
|
paul@28 | 412 |
|
paul@30 | 413 | Constant Attributes
|
paul@30 | 414 | -------------------
|
paul@30 | 415 |
|
paul@30 | 416 | When accessed via "safe containers", as described above, any attribute with
|
paul@30 | 417 | only one recorded assignment on it can be considered a constant attribute and
|
paul@30 | 418 | this eligible for optimisation, the consequence of which would be the
|
paul@30 | 419 | replacement of a LoadAttrIndex instruction (which needs to look up an
|
paul@30 | 420 | attribute using the run-time details of the "container" and the compile-time
|
paul@30 | 421 | details of the attribute) with a LoadAttr instruction.
|
paul@30 | 422 |
|
paul@30 | 423 | However, some restrictions exist on assignment operations which may be
|
paul@30 | 424 | regarded to cause only one assignment in the lifetime of a program:
|
paul@30 | 425 |
|
paul@30 | 426 | 1. For module attributes, only assignments at the top-level outside loop
|
paul@30 | 427 | statements can be reliably assumed to cause only a single assignment.
|
paul@30 | 428 |
|
paul@30 | 429 | 2. For class attributes, only assignments at the top-level within class
|
paul@30 | 430 | definitions and outside loop statements can be reliably assumed to cause
|
paul@30 | 431 | only a single assignment.
|
paul@30 | 432 |
|
paul@30 | 433 | All assignments satisfying the "safe container" requirements, but not the
|
paul@30 | 434 | requirements immediately above, should each be recorded as causing at least
|
paul@30 | 435 | one assignment.
|
paul@28 | 436 |
|
paul@29 | 437 | Additional Controls
|
paul@29 | 438 | -------------------
|
paul@29 | 439 |
|
paul@29 | 440 | For the above cases for "container" objects, the following controls would need
|
paul@29 | 441 | to apply:
|
paul@29 | 442 |
|
paul@29 | 443 | 1. Modules would need to be immutable after initialisation. However, during
|
paul@29 | 444 | initialisation, there remains a possibility of another module attempting
|
paul@29 | 445 | to access the original module. For example, if ppp/__init__.py contained
|
paul@29 | 446 | the following...
|
paul@29 | 447 |
|
paul@29 | 448 | x = 1
|
paul@29 | 449 | import ppp.qqq
|
paul@29 | 450 | print x
|
paul@29 | 451 |
|
paul@29 | 452 | ...and if ppp/qqq.py contained the following...
|
paul@29 | 453 |
|
paul@29 | 454 | import ppp
|
paul@29 | 455 | ppp.x = 2
|
paul@29 | 456 |
|
paul@29 | 457 | ...then the value 2 would be printed. Since modules are objects which are
|
paul@29 | 458 | registered globally in a program, it would be possible to set attributes
|
paul@29 | 459 | in the above way.
|
paul@29 | 460 |
|
paul@29 | 461 | 2. Classes would need to be immutable after initialisation. However, since
|
paul@29 | 462 | classes are objects, any reference to a class after initialisation could
|
paul@29 | 463 | be used to set attributes on the class.
|
paul@29 | 464 |
|
paul@29 | 465 | Solutions:
|
paul@29 | 466 |
|
paul@29 | 467 | 1. Insist on global scope for module attribute assignments.
|
paul@29 | 468 |
|
paul@29 | 469 | 2. Insist on local scope within classes.
|
paul@29 | 470 |
|
paul@29 | 471 | Both of the above measures need to be enforced at run-time, since an arbitrary
|
paul@29 | 472 | attribute assignment could be attempted on any kind of object, yet to uphold
|
paul@29 | 473 | the properties of "safe containers", attempts to change attributes of such
|
paul@29 | 474 | objects should be denied. Since foreseen attribute assignment operations have
|
paul@29 | 475 | certain properties detectable at compile-time, it could be appropriate to
|
paul@29 | 476 | generate special instructions (or modified instructions) during the
|
paul@29 | 477 | initialisation of modules and classes for such foreseen assignments, whilst
|
paul@29 | 478 | employing normal attribute assignment operations in all other cases. Indeed,
|
paul@29 | 479 | the StoreAttr instruction, which is used to set attributes in "safe
|
paul@29 | 480 | containers" would be used exclusively for this purpose; the StoreAttrIndex
|
paul@29 | 481 | instruction would be used exclusively for all other attribute assignments.
|
paul@29 | 482 |
|
paul@43 | 483 | To ensure the "sealing" of modules and classes, entries in the attribute
|
paul@43 | 484 | lookup table would encode whether a class or module is being accessed, so
|
paul@43 | 485 | that the StoreAttrIndex instruction could reject such accesses.
|
paul@43 | 486 |
|
paul@28 | 487 | Constant Attribute Values
|
paul@28 | 488 | -------------------------
|
paul@28 | 489 |
|
paul@29 | 490 | Where an attribute value is itself regarded as constant, is a "safe container"
|
paul@29 | 491 | and is used in an operation accessing its own attributes, the value can be
|
paul@29 | 492 | directly inspected for optimisations or employed in the generated code. For
|
paul@29 | 493 | the attribute values themselves, only objects of a constant nature may be
|
paul@28 | 494 | considered suitable for this particular optimisation:
|
paul@28 | 495 |
|
paul@28 | 496 | * Classes
|
paul@28 | 497 | * Modules
|
paul@28 | 498 | * Instances defined as constant literals
|
paul@28 | 499 |
|
paul@28 | 500 | This is because arbitrary objects (such as most instances) have no
|
paul@28 | 501 | well-defined form before run-time and cannot be investigated further at
|
paul@28 | 502 | compile-time or have a representation inserted into the generated code.
|
paul@29 | 503 |
|
paul@29 | 504 | Class Attributes and Access via Instances
|
paul@29 | 505 | -----------------------------------------
|
paul@29 | 506 |
|
paul@29 | 507 | Unlike module attributes, class attributes can be accessed in a number of
|
paul@29 | 508 | different ways:
|
paul@29 | 509 |
|
paul@29 | 510 | * Using the class itself:
|
paul@29 | 511 |
|
paul@29 | 512 | C.x = 123
|
paul@29 | 513 | cls = C; cls.x = 234
|
paul@29 | 514 |
|
paul@29 | 515 | * Using a subclass of the class (for reading attributes):
|
paul@29 | 516 |
|
paul@29 | 517 | class D(C):
|
paul@29 | 518 | pass
|
paul@29 | 519 | D.x # setting D.x would populate D, not C
|
paul@29 | 520 |
|
paul@29 | 521 | * Using instances of the class or a subclass of the class (for reading
|
paul@29 | 522 | attributes):
|
paul@29 | 523 |
|
paul@29 | 524 | c = C()
|
paul@29 | 525 | c.x # setting c.x would populate c, not C
|
paul@29 | 526 |
|
paul@29 | 527 | Since assignments are only achieved using direct references to the class, and
|
paul@29 | 528 | since class attributes should be defined only within the class initialisation
|
paul@29 | 529 | process, the properties of class attributes should be consistent with those
|
paul@29 | 530 | desired.
|
paul@29 | 531 |
|
paul@29 | 532 | Method Access via Instances
|
paul@29 | 533 | ---------------------------
|
paul@29 | 534 |
|
paul@29 | 535 | It is desirable to optimise method access, even though most method calls are
|
paul@29 | 536 | likely to occur via instances. It is possible, given the properties of methods
|
paul@29 | 537 | as class attributes to investigate the kind of instance that the self
|
paul@29 | 538 | parameter/local refers to within each method: it should be an instance either
|
paul@29 | 539 | of the class in which the method is defined or a compatible class, although
|
paul@29 | 540 | situations exist where this might not be the case:
|
paul@29 | 541 |
|
paul@29 | 542 | * Explicit invocation of a method:
|
paul@29 | 543 |
|
paul@29 | 544 | d = D() # D is not related to C
|
paul@29 | 545 | C.f(d) # calling f(self) in C
|
paul@29 | 546 |
|
paul@30 | 547 | If blatant usage of incompatible instances were somehow disallowed, it would
|
paul@30 | 548 | still be necessary to investigate the properties of an instance's class and
|
paul@30 | 549 | its relationship with other classes. Consider the following example:
|
paul@30 | 550 |
|
paul@30 | 551 | class A:
|
paul@30 | 552 | def f(self): ...
|
paul@30 | 553 |
|
paul@30 | 554 | class B:
|
paul@30 | 555 | def f(self): ...
|
paul@30 | 556 | def g(self):
|
paul@30 | 557 | self.f()
|
paul@30 | 558 |
|
paul@30 | 559 | class C(A, B):
|
paul@30 | 560 | pass
|
paul@30 | 561 |
|
paul@30 | 562 | Here, instances of B passed into the method B.g could be assumed to provide
|
paul@30 | 563 | access to B.f when self.f is resolved at compile-time. However, instances of C
|
paul@30 | 564 | passed into B.g would instead provide access to A.f when self.f is resolved at
|
paul@30 | 565 | compile-time (since the method resolution order is C, A, B instead of just B).
|
paul@30 | 566 |
|
paul@30 | 567 | One solution might be to specialise methods for each instance type, but this
|
paul@30 | 568 | could be costly. Another less ambitious solution might only involve the
|
paul@30 | 569 | optimisation of such internal method calls if an unambiguous target can be
|
paul@30 | 570 | resolved.
|
paul@30 | 571 |
|
paul@29 | 572 | Optimising Function Invocations
|
paul@29 | 573 | -------------------------------
|
paul@29 | 574 |
|
paul@29 | 575 | Where an attribute value is itself regarded as constant and is a function,
|
paul@29 | 576 | knowledge about the parameters of the function can be employed to optimise the
|
paul@29 | 577 | preparation of the invocation frame.
|