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.
SourceForge.net Logo Copyright (c) 2005, 2006, 2007 Peter Kehl