> Three I can think of -- 1) the make-widget-place-writer problem > described above,
I don't really consider this to be a problem. The protocol is in place and we'd just need to supply a small adapter. > 2) the need to supply an *additional* enumeration function > (which means lots of fun with method combinations to make it > work), What needs to be enumerated, and how? > and 3) if you want to control rendering in your specialized > subclasses, they still need to "know" about these slots and reference > them directly, which I'd say is just as clumsy as the solution I > implemented. Yes, there's not really a difference. Children classes often need information about their superclasses and that can't be avoided. Either way we can supply a function that returns a widget's children without this additional information. > Of course there is also a small (4) -- get/set-children-of-type always > operates on lists, promoting widgets to lists if necessary, which means > you always use map on what get-children-by-type returns. > > But, I think the only way to really know is to try -- I did, rewrote the > code a couple of times and ended up with a solution that is a > compromise. Like I said, I'm not that enthusiastic about it, but I think > it isn't such a bad compromise. If someone comes up with a better > working solution, I'd be more than happy to migrate. What I'm trying to figure out right now is what should be at the core. Custom accessors can be provided above children-of-type and children-of-type can be implemented atop of slots. The latter solution seems more natural and effective to me, but I'm still very open to be convinced of the converse. It would be good if Stephen and Slava participated again in this discussion. By the way it's nice to see that we apparently have an agreement about the other 80% of navigation-rewrite. :) --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "weblocks" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/weblocks?hl=en -~----------~----~----~----~------~----~------~--~---
