[PEAK] PEAK-Rules vs RuleDispatch.

[Phillip J. Eby]

At 10:06 AM 1/15/2007 +0100, Elvelind Grandin wrote:
>How is the development of PEAK-Rules going.

Due to working two jobs (my day job and my self-help author/speaker/etc. 
"job"), it hasn't been going at all, actually.


>Is it ready to replace ruledispatch any time soon?

If I had say, 5 days to devote to it, or even 5 days of doing only one of 
my "jobs", it could be done.  All of the library bits are in place already, 
including code generation, parsing, the tree builder algorithm, method 
combination, etc.  It's just lacking indexes and glue code, i.e., the bits 
to tie the tree builder to the code generator to the indexes to an 
engine.  It might not even take 5 days.

But right now I don't know when I could have those days.  There seems to be 
no chance of that in January, and little chance in February.

And to be honest, among the projects I would work on with that kind of 
spare time, PEAK-Rules is not first on the list at the moment.  I would 
probably want to work on finishing Contextual first, as it's more likely to 
have immediate application in paying projects (like my day job).

That doesn't mean I wouldn't do it for TG's sake, but connection to a 
paying project would make a huge difference in how soon it gets 
done.  Really, that's why most of PEAK has been lagging in new features the 
last couple years: my "day job" working on Chandler so far uses only 
setuptools, simplegeneric, and SymbolType out of the entire PEAK family of 
projects.  There is also some chance for Contextual and Trellis to get used 
later...  maybe.

So at least in the last year, PEAK has only been getting new features (e.g. 
some recent SQL tweaks) when I need them for side jobs like data migration 
projects for my wife's store.