paul@201 | 1 | Namespace Definitions
|
paul@201 | 2 | =====================
|
paul@201 | 3 |
|
paul@201 | 4 | Attributes can be redefined in modules and classes, but this eliminates much
|
paul@201 | 5 | of the potential for optimisation. However, names of classes and functions
|
paul@201 | 6 | could be restricted to only refer to the same kinds of objects within the same
|
paul@201 | 7 | namespace. If redefinition were to occur, or if multiple possibilities were
|
paul@201 | 8 | present, these restrictions could be moderated as follows:
|
paul@201 | 9 |
|
paul@201 | 10 | * Classes assigned to the same name could provide the union of their
|
paul@201 | 11 | attributes. This would, however, cause a potential collision of attribute
|
paul@201 | 12 | definitions such as methods.
|
paul@201 | 13 |
|
paul@201 | 14 | * Functions, if they share compatible signatures, could share parameter list
|
paul@201 | 15 | definitions.
|
paul@201 | 16 |
|
paul@201 | 17 | It is easier, however, to regard multiply defined classes and functions as
|
paul@201 | 18 | non-constant and to either disallow optimisations or to actually prevent the
|
paul@201 | 19 | program describing them from compiling.
|
paul@771 | 20 |
|
paul@771 | 21 | Note that the same static definition may be multiply defined, such as a class
|
paul@771 | 22 | with parameterised attributes or a function with parameterised defaults (or
|
paul@771 | 23 | even closures referencing external state). Such parameterisation does not
|
paul@771 | 24 | attempt to reconcile completely different static definitions, however, and
|
paul@771 | 25 | should be handled separately.
|