Log of /Contextual/README.txt

Parent Directory

No default branch
Bookmark a link to HEAD: (view) (download)

Use development snapshots so SVN isn't required

Doc tweaks

Packaging cleanups for Cheeseshop registration.

More tests, API tweaks, add a bit of docs.

Overhaul front-end API to "setting", "resource", "registry", and
"resource_registry" (not tested/available yet).  This is the absolute
minimum number of elements to express the full possible generality,
at the cost of having to use fixed parameter names to denote the
nature of a setting (or resource's) input.  A parameter of 'expr'
means that the configuration will be lazy, and 'value' means it will
be eager.  There is no other real effect.  The system now allows full
generality in how input values are transformed to outputs (and/or
validated).

This pretty much nails the front-end API to something usable, and I
intend to actually begin using it now.  Everything should now be in
place to implement configuration files, too, although for now I plan
to just use Python code.

Added context.new() and context.empty(), along with a "root" state that
holds only rules, not results (analagous to the old Config.root object).
More "namespace" tests.  ``.*`` rules still need some work before config
files can be implemented, but most of the needed infrastructure is now
in place.

Get rid of ``namespace``, and make all settings namespaces.  Settings
are now objects that pretend to be functions, instead of actually being
functions.  This is slightly slower, but the simplification and extended
syntax capabilities are worth it.  This thing is getting really close to
being usable now.

Implement better scoping, by allowing states to be context managers.
Also, renamed setting->value and parameter->expression.  Expressions
scan be scoped to services, such that a "resource" is just an
"Action.expression" (i.e. an expression scoped to the nearest Action
service).  Instead of using 'with service_instance:', you now use
'with service_class.new():' to replace a service.

The next refactoring will change keys from being functions, to being
objects, allowing them to be set to either values or expressions
dynamically.  As a side-effect, this will drop the dependencies to
both the SymbolType and ProxyTypes packages, although that's not the
reason for doing it.  The real reason is that it will allow things
like this::

    with context.new():
        some_var  <<  some_value
        other_var <<= lambda:some_expression
        # code that uses these variables

as the canonical way to set variables in a context. 

Another major refactoring -- merged Config and App into State, and
implemented dynamic state propagation that eliminates the need to
explicitly define ServiceAreas the way the PEAK core does.  This
new system is 100% lock-free and thread-safe (assuming that your own
code is, too!) and has a smaller, friendlier API than the previous
half-dozen attempts.  The core state management system is now
rock-solid, but there are a few minor areas where protocol changes
may occur.  See the "TODO" section in README.txt for details.

Misc. cleanups, more API doc and tests

Major API overhaul.  Service classes now act like peak.binding.Singletons,
in that the class itself is a proxy for the current instance.  This
eliminates the need for two names to refer to the "same" object.  Settings
are now created with decorators, the module is peak.context instead of
peak.util.context, and many many other changes.  And there are still more
to come, but mostly additions and some tweaks to how the App context works.

More work on docs

Make README testable, add new files that 'context.txt' will be 
refactored into.  Add 'context.replaces()' class decorator to make it 
easier to define an alternative service implementation.

Refactor class hiearchy slightly, and add a README that presents the 
library as it should be seen on PyPI.  Still a lot of cleanup to do and 
tests to add, though.