Re: history

[Will P. <pa...@dc...>]

Rudolph Pereira continues:

> To put it as generally as possible, it would be nice to
> have the state appearing as part of the object, and not
> just stored on the machine itself. ...

(I am still wondering about the "nice to have" vs the "no
possible way can I do something cool without it" question
:-)

One way to think about the "little .xml files with
<prototypes>" in them: ARK semantics say you should be able
to "pre-process" away the prototypes.  That is, you could
expand the <prototypes> and then hang onto the expanded
stuff in another .xml file and then just use that.

And since doing the prototypes expansion is a lot like doing
C pre-processing, you might as well accumulate the
dependency info ("foo.xml depends on prototype
"bar/baz.xml") and set up a makefile using it.  That could
be used to keep all of your expanded "objects" up-to-date.

Even then, though, the situation is far from perfect.  In
the code for some method (now expanded out), you might make
mention of '/our/bin/gcc'.  Well, six months ago, that meant
GCC 3.1, but now it means GCC 3.3.1.  You haven't captured
that change.

Even if you get around that one, there are still similar
problems for the truly paranoid.  Every time you apply a
patch bundle from Sun (say), it may change how
/usr/bin/touch or /bin/ls works (well, *maybe*...) or
[perhaps more significantly] some library API will wobble at
the edges.  And your expanded-ARK-objects stuff will miss it
entirely, unless you take extra measures.

The business of recording what-a-method-did along with its
specification (i.e. code) is different from usual object
thinking; but nothing inherently wrong with it.  I
personally don't have a problem that the source
(specification) is in one directory and the
what-happened-when-I-ran-it info is in another.  Each one
can be managed with as much or little care as you like.

But, hey, this is a *dev*elopment list... give us a use case
or two, and we might even help :-)

Will