Techniques and Frameworks
Our technique opens a fresh dimension of design patterns. Along with some
restrictions, there emerge new features which simplify some designs.
This is not a set of general design patterns and their classes in the same
way as the one by Rose of Four. Although those involve some shared immutable
objects, they more often use changeable components.
- passing by value or passing by reference
- deep querying - visitor mechanism
Element/Mutation Producer/Consumer
Passing/returning mutation collector Element, and applying that mutation in
target Context.
Mutation collector
It's a special relaxed Element with changeable fields. That pushes the idea
to It inherits from Element, so that its seed can be mirrored. This allows
any Elements access it. It contains mutable map [Element => Mutant] and a
graph of dependencies between Elements (retrieved from Reference fields).
Visitor Condition-Action mechanism
- deep in-place evaluation
-------------------------------
Cached Element - otherwise Element is leightweight, ie it doesn't cache
component Elements, and associates them with their Context on demand
------@TODO check that cached elements have correct Context, ie different
than owner's Context - they need owner's Context + owner Element in it
@SMILE:
Let's have a modification (mirror) MyComposite of a reusable composite
CompositeSeed. Now even if type-safe, we can't make another mirror of
CompositeSeed within MyComposite, because that would shadow the current
MyComposite and it couldn't create a new modification mirror of
CompositeSeed.
Our goal could be accomplished by creating AnotherComposite, an auxiliary
mutation of CompositeSeed outside the Context of MyComposite. Than we can
pass AnotherComposite down to MyComposite, mutate it and use. Backward
references from components to composite will now resolve properly, because
there is a "separation space".
@COMPLEX
When identity of target of a shadowed Elem is the same as another
non-shadowed reference, then they are equal obviously. However, when shadowed
reference is passed up(), then it's resolved back to its original(s)
according to the chains of its applied mirrors; while the other reference is
not affected.
Therefore Elems must be compared by value, but must not assume the same value
will be passed up().
However, if any of these two references is passed down dw(), they both get
shadowed by same mirror chains in exactly same way.
|
Copyright (c) 2005, 2006, 2007 Peter Kehl
|