Well, we don't want to end up with more lines of test code than program code. So I'd leave that to the debugger for now ;-)
Not an XP fan? :) Cells is pretty stable (but that will come unglued if people like you and Andy keep showing up) but I love taking things that go wrong and throwing them into a regression test suite precisely so I can continue hacking like a cowboy and then just re-running the test to see what broke, and if nothing breaks the code is declared perfect cuz if there is any behavior one does not like one has to get into the regression test.
You got a point here: It does make hacking safer. In general, XP always sounded kinda strange to me, though; I feel I trust a function more when it looks well-written than when it passes *some* test.
Maybe that's just because I am not good at writing solid tests. When I write test code it usually only reflects the angle I am looking from at the time of writing and thus becomes rather one-sided. Toss the code in a real world scenario, and the requirements are everything but what I wrote in the tests. And knowing my defencies at writing tests, I rather try to write sound code in the first place than to rely on my (tainted) tests.
It looks quite different in the case you point out, however:
I know the XP guys write the tests first -- that might be a good policy for RFEs: if someone wants something changed they have to specify it in the form of a test that will not pass now. Just a great exercise for clarifying what one wants, seeing if it might already be there, and doing so in a way that guarantees no future change will back it out.
i.e. when the person writing the test is the user of the functionality, not the one who implements it. That makes perfect sense to me, then.
I will try to adapt this idea and post future requests here in the form of a stand-alone piece of code which would work if cells worked the way I want it to.
(Sorry, just thinking out loud here.)
Nothing better than that on a rainy afternoon. :)
So my question becomes: How old can the value in the c-value slot
Ah, I was wondering why you were surprised that 3 had gotten through. A naked SETF ends up wrapped in a within-integrity call that ensures data integrity as defined in cells-manifesto.txt (half-way in look for a list of a half-dozen things defining "integrity"). I think that will clarify things greatly.
Thanks for the pointer! I have read the manifesto a while ago (when I got started with cells), but it makes a lot more sense now :)
So if it will actually become an issue, we can still go back and invent the :death-bed stage in which not-to-be's are called after all changes have been propagated.
Right, a new :ex-parrot unfinished-business queue to be processed before (I suppose) looking for a new change perhaps kicked off by an observer.
Yep, I guess the perfect order would be along these lines:
- a change occurs - build dependency tree - find one or more changes of kids slots in the tree - do a *dry run* of the propagation to figure out what the new kids would be - call all relevant not-to-be's (which need to defer calls to setf with with-integrity) - then do the actual propagation - call observers - run the defered stuff
i.e. one would need to figure out the changes to kids slots, but the n run not-to-be while the system is still in pre-propagation state, so that not-to-be code can use stuff "as if it was still alive".
As I said before, I doubt that the effort for this kind of modification is justified. Let's hack on until we really need that.
Right, it's a lost cause. The Real Problem is not clearly dividing model-time from non-model-time by doing anything modelly during not-to-be. It was a bit extreme (as I once had it and did again by mistake) to force... ha, maybe that /is/ the way to go, force them to use slot-value. I like things like that that say to the user "I do not think you will forget you are in not-to-be as long as only slot-value works.
While we are at it, maybe we should introduce mandatory type declarations for ruled and input cells? :->
Cheers Peter