[PEAK] PEAK-Rules vs RuleDispatch.
Phillip J. Eby
pje at telecommunity.com
Mon Jan 15 11:55:59 EST 2007
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
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.
More information about the PEAK