|
|
Requirements
- easy to use - minimum
restrictions for application
- code
- variables
- function calls or special parameters passed along
- components should usually be accessed within Context of their
containers
- instruments to create new graph(s) based on another (original)
graph
- extensible
- users can derive own classes
- easy to integrate
- objects can be passed to 3rd party modules and they can
be accessed from there
- compatible
- implementation doesn't depend on specific platform/compiler
- safe
- assertions
- type-safe
- generics
- proof hints for non-trivial assumptions
- test units
- implementable - reference
implementation is in Java 1.5 and is portable to any language which
has:
- garbage collecting (GC), otherwise
- C++ local objects could be used without GC, but
- multithreading - would be restricted or slow
- new threads would have to finish before parent thread
returns from current function
- or Context chains are copied before passed to new
threads - which slows processing down
- there are no real benefits of local objects, because
- copying of local objects takes processing time
- except for ElementPures, all entities can be
- reference-counted or
- released in LIFO order (Last In First Out)
- custom memory management is used for Context-associated
Elements, which
- must be allocated dynamically because their type is unknown
at compile time
- are allocated and released in stack behaviour, but are one
level delayed behind popping the method call stack
- custom memory management used for ElementShadowed
- need to be allocated dynamically
- core classes can't determine when to release these instances
- unless they are always copied by value rather than
shared
- that's because ElementShadowed are used by any number
of Element object
- Context instances can be shared, and they are never cyclic
- ElementPureContainers can be recursive, therefore they require
- automatic GC or
- application-controlled GC
- that may be be unpredictable, complex and unsafe,
therefore not suitable for
- integration with 3rd party modules
- use in a continuous system
- identity comparison of objects
- identity-based maps
- object locking - if multithreaded
- generics - useful, but not required
Limits
- passing of arguments to functions and returning results
- global and class-shared objects
- multiple threads
- function headers
- inner classes, closures (objects of local anonymous classes)
Side products
Several automation tools were developed. Their features are
- easy to use
- thread-safe
- fast
- except for Spread Variables - which is intended for debugging
They are
- Spread Variables - thread-specific variables
- they are a debugging and assertion tool which
- helps to detect and locate nonstandard situations
- suits complex, deep and recursive method calls
- is accessible in deeper method calls
- can be overwritten in deeper calls, which doesn't affect the
values in higher call stack
- compatible with 3rd party modules
- package net.sf.reuse.debug
- Lockable Objects
- such an object can be locked, and then it's accessible from current
thread only
- used for chains of modifications applied to ElementMutant
- package net.sf.reuse.lock
- Thread-Shared Structures
- global heap, consisting of immutable snapshots
- thread-specific reference to immutable snapshot of global heap
- Deferred Evaluation
- used for Element components of containers, and hash code
- package net.sf.reuse.defer
- Hash partitioning for fast shortcuts
in linked maps
- package net.sf.reuse.area
|