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 3
rd
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
use reference counting
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 3
rd
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 3
rd
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
Copyright (c) 2005, 2006, 2007 Peter Kehl