On Wed, Jul 31, 2002 at 07:19:57PM +0100, John Levon wrote: > On Wed, Jul 31, 2002 at 08:03:51PM +0200, Andre Poenitz wrote: > > > > except we don't replicate the code for a map in each inset. > > > > There would be one map<action, callback> _per class_. That's not > > expensive. > > OK, so basically you're devolving one level of the two-level > action->handler map into the inset class. Hmm. > > Not sure how that would work out. For one thing the inset classes are > way too big already.
What is 'way too big'? The interface for the base class? The size of the code? > Yeah, not a big deal > > > [This inset locking stuff should go ASAP IMNSHO] > > Sure, but I'd love to see you handling the contained inset stuff :) Look at mathed. Things are nesting fairly nicely there. > > In my version an inset would simply shrink the cursor by one level in > > this case and let the "Right" action intact. Then the parent of the > > inset sees the "Right" action and does its thing... > > Right. Analgous but probably a lot cleaner. Until we find all the painful > special cases. In many ways this stuff goes hand in hand with your plans. Unless you come up with such a case, this is FUD. > > Okokok. Then get the "small things" right and I won't complain. > > Well I'm not sure it's worth expending effort on code I'm not sure is > workable or a good idea I find the decentralization of dispatch a Good Idea. Actually, the misuse of the math cursor as "moving dispatcher" is (apart from the interface to the outer world) _the_ dirty corner in mathed. So I'd like to get rid of it anyway, and that's why I pondered the issue and that's why I have some idea how _I_ would implement it. Now, although your idea is not exactly the same it goes quite some way into the same direction and it is difficult to tell in advance which would work out better. So I'm certainly not opposed to it. Andre' -- Those who desire to give up Freedom in order to gain Security, will not have, nor do they deserve, either one. (T. Jefferson)
