Sounds good. I wasn't sure as to whether I understood what I was doing. I just saw that not-to-be did not propagate to kids *at all* if I did it the way I suggested.
OK.
That was with test-gtk -- my favorite test case. Upon a not-to-be on test-gtk nothing gets propagated. the class hierarchy is test-gtk->gtk-app->window->container->widget->gtk-object->family. But, no, there is no kids slot redefined anywhere.
Hold on, one idea: Maybe the problem is with
(get (type-of fm) :ownings), i.e. this only picks up the owning defined on the actual class of fm, not the inherited ones?
To be honest, I am just doing wild guesswork here, so I better shut up :-)
No, you are hot on the trail. I have code which tries to propagate the :owning declaration up and down the class hierarchy, so I wager there is a bug in there. And having revisited this, I find myself not liking the idea of propagating a slot attribute that way, tho I guess propagating down is what other slot attributes do when a slot is reiterated but with some attributes not specified. I may ask the c.l.l yobbo language lawyers what they think.
Sounds like the sensible thing to do (for I have no idea what is the right way to do this. Traversing the whole hierarchy every time a not-to-be is called in order to collect the list of slots seems wrong ;-))
Hope you guys had a good time in Amsterdam. Hopefully next year I will actually make it :-)
Everything but the talk itself was a blast. It is so great hanging out with Lispers in large quantities. As for the talk, I am tempted to set up my camcorder and do the talk again for YouTube.
That'd be great :-)
:( But based on post-talk reaction at least I was understood. A Lispworks guy wanted to talk about how hard it must be to debug the damn things. I said, No and yes, the yes being that I have always antancipated that as non-experts get involved better diagnostics/debug/trace tools would be needed.
Agreed. It took me a while to make sense of the cells heavy backtraces I get if I make a silly mistake in a cells rule. OTOH, trc/wtrc do a good job for me (I learned programming ona Commodore 64, so I don't mind print statements as my prime debugging tool. I still maintain that a sensible number of print statements is often a better debugging tool than all the stuff the IDE has to offer -- that is, my emacs/slime/sbcl yobbo IDE ;))
I'll be revising the not-to-be thing and look at why kids did not get handled -- good to have a smoking gun to debug. Oh, wait -- what was the class? My guess is one that reiterated the kids slot instead of just supplying a default initarg.
As I said before, I did not see anything like that between family and test-gtk. Hmmm.
I'll try and single out a test case.
Thanks, Peter