On Sat, May 04, 2013 at 03:27:41PM -0400, Wayne Stambaugh wrote: > The advantage of the proxy object is that the bloat and/or coupling > is contained within the object which tends to make it more visible.
Possibly. Never had the issue in the first time so I don't really know. Most of the programming I am involved in are anti-bloat by requirement (C and assembly and maybe some rich 0.5K of ram available:D) > This case was easy to find. The more insidious case is were it's > buried two or three functions calls down stack. You can easily > couple objects this way without even realizing it. Well, look at the function signatures; unless there are globals involved the stuff can only come from there :P > I'm not sure what Dick's intentions are here but I doubt he is > talking about one huge object with all of the actions built into it > unless it's something like the PAINTER object currently being use as > part of the new rendering design. Perhaps the mixin is more of an > action manager rather the actions themselves. Something like a wxDC has to have a lot of functions, by requirement. However it only does drawing. You could look at it in this way if you put all the stateless procedural code into BOARD; that would be a perfectly fine place to put board actions, of course. However that would lead to an 'abuse' of member access privileges; I don't really think so highly of the 'accessor' based designs (I found that every time I changed some internal representation the accessor interface wasn't correct anyway so it propagated to the rest of the world), since I prefer slot-based languages; however in C++/Java it's idiomatic to use them, so it's fine, is only a little nuisance to define all these trivial get/set methods (at least CLOS generates them for you, if you ask for them) An action manager as mixing would make sense (but why inheritance instead of aggregation? the 'private inheritance as aggregation' of C++ smells a lot of trick to me) but I can't imagine why board actions would have to be managed... I think that now we only have to wait for a better explanation from Dick (I reread the old thread but nothing popped up) > As soon as you start combining other trace operations, you make > command substitution much more complex. The 'related' is an issue of granularity; of course with a true command (which keep as a state both the operation *and* what it would need to undo it, something like a transaction log) the only way to implement it cleanly is one command for operation (inheritance helps here). The example Save/SaveAs is a little far fetched (Save is actually SaveAs with a default argument...) > I would not surprised if this were the case. I'm am coming to the > conclusion that email is not the most effective way to communicate > ideas. I find that code examples (either my own or a link to an > example) do a better job of explaining my ideas than several > paragraphs of detailed explanations. As you may have noticed I try to do examples (maybe in pseudocode) exactly for that reason; maybe it's simply that, since english is not my main language, I can't properly express using the 'right' nuances (and often I don't understand Dick metaphors:P:P) -- Lorenzo Marcantonio Logos Srl _______________________________________________ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp