Ancillary logic ideas

[Josh Sled]

On Fri, 2005-09-09 at 22:32 +0100, Neil Williams wrote: 
> On Friday 09 September 2005 2:28 am, Josh Sled wrote:
> > On Thu, 2005-09-08 at 22:40 +0100, Neil Williams wrote:
> > > The ancillary logic, therefore, does need to be moved between files -
> 
> > Maybe.  It's certainly a misnomer to call it "ancillary"; I'd consider
> > it the majority of the value of the codebase.
> 
> True! What would you propose instead?

I'm not sure yet, which is partly why I'm not proposing something. :)

As you point out, there seems to be a "low" logic around field- and
object-integrity checks... something akin to validation... as well as a
"high" logic regarding object-construction and subsystem-usage.

I believe validation is best done declaratively.  A list of tuples of
{field-getter, data-type-constraint}.  Data-type constraints are
generally above-and-beyond those provided by programming languages, such
as "positive integer", "bounded integer", "length-limited string",
"patterned string", &c.  It's only a small step to consider fields being
valid as a function of the validity and/or value of other fields.  And
only slightly more complexity to operate on object-graphs and
collections.

(There is also is more than one level of integrity, here.  For instance,
gnucash would function perfectly well if no Account had a name or
description... the types, guids and parent-guids are all that are
strictly required.  But in any practical user interface, every account
should have a name that is non-null and unique.  I guess this primarily
extends to user-facing identifiers like names, but I think it's worth
distinguishing assertion-level constraints like "all splits must
reference an account" and practical constraints like "all accounts much
have a unique name".)

The "high" logic, I believe, has two parts: the data-types and functions
which define the semantics of the application, and the user interface
which defines the "syntax" of an application, if you will.  These things
are often very closely related, which is harder to generically abstract.
The best that people have seem to come up with so far is the
Model-View-Controller architecture.

The mortgage loan druid is a decent example: I took care to seperate the
GUI/druid controller from the loan-parameters/options and processing
model... and even still the model-only code tacitly assumes a druid-like
interface.  Some other GUI could -- if the appropriate piece was to move
from the druid into the engine -- use that same model to re-present
similar functionality.


> > And 
> > given the current user-interface flow between the pages in the
> > since-last-run dialog, there's some re-computation of the transaction
> > that occurs.  But all that can be abstracted away...
> 
> Great. I'd like to help with that.

This has pretty low priority on my todo list right now; I'm more than
happy to review proposals, designs and code, though.


> > This sounds like value validation.  I think it's best handled
> > declaratively, but it's pretty straightforward to do procedurally.
> >
> > I'm not sure this is the hard part to abstract out, though.
> 
> Please elaborate - it is exactly these points that I need to clarify before 
> working on the abstraction.

I think the validation is hard enough and somewhat valuable, but the
*real* value is saving any work that would be re-implementation of the
application logic.

For example, I can easily see a set of rules declared that enable
runtime input validation for SXes, thus refactoring some code out of the
current SX editor and as such re-usable by a CLI, but I think there's a
fair amount of code that is not readily factored out, and I'm not sure
how to deal with.  I can imagine that most of the non-UI logic can get
factored out into a better Model, and the CLI View/Controller could call
it as well as the GUI View/Controller, but I think there's a large
amount of reimplementation just in the view/controler side, too. :(

(I use SXes as my examples here due to familiarity, but I don't think
there's anything in particular that biases them as an example.)


Of course, some of the above costs assume feature parity between the GUI
and CLI versions of gnucash...  what's your goal for CashUtil?  Is it a
CLI interface to all of gnucash, or a basic access to a subset of
gnucash?

...jsled
-- 
http://asynchronous.org/ - `a=jsled; b=asynchronous.org; echo ${a}@${b}`