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