kicad-developers team mailing list archive

[Lorenzo Marcantonio <l.marcantonio@xxxxxxxxxxxx>]

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