kicad-developers team mailing list archive

["Brian F. G. Bidulock" <bidulock@xxxxxxxxxxx>]

Vladimir,

On Fri, 25 Nov 2011, Vladimir Uryvaev wrote:

> Though accessors it widely used way, they're not self worth feature.
> Accessors are useful when:
> - Class should re-render (cache, graphic or whatever) on its attribute change.
> - Notifications about changes should be sent to another object.
> - Other attributes should change coherently.
> - I forget.
> 
> There are two data storage 'paradigms':
> - true object having designed interface with all its internals hidden,
> - plain old data type with free access.
> In most cases it is good to head toward one of them. Accessors are seem to be 
> emulation of POD in true object.
> 
> Instead of accessors it is better to design proper interface, specific to its 
> usage. Making accessors first, then proper interface one could do double work. 
> So IMO we could make interfaces right off without intermediate work on 
> accessors.
> 
> For example, there could be:
> Geometric Interface, applicable to every object on the board (and scheme 
> sheet).
> Connectivity Interface, applicable to every electrically connectible object.

True, somewhat.  I already wrote the proximity map (geometric registration
and hid it inside the geometric objects) and the connectivity map (well,
directed graph really) and hid that inside the conducting objects.  Also long
as the position of critical points of the object (track, pad, whatever) are
delivered to the object using accessor functions, the proximity maps and
connectivity graphs are automatically updated.

(I will strap all this stuff in on an experimental branch when we can get
 there.)

It sounds like you are thinking that geometric and connectivity manipulations
are done outside the objects.   I did them inside the objects, where they
belong, so that proximity maps and connectivity graphs could be updated without
the caller needing to worry about them.

The problem without this approach is that the code external to the object
keeps putting objects on and taking them off and sorting them on all these
auxilliary lists external to the objects.  These work for boards with a small
number of features.  My board with the 7000 features takes two minutes to
load on a very very fast machine.  Also, editing starts crawling slower and
slower (several second freezes) with the addition of every new copper feature.
The existing lists simply compare one object to too many other objects that
are nowhere near it.  All of these lists are part of the legacy.

But if your just talking factoring setX() and setY() into move() off the
bat without stepping through setX() and setY(), then all I would say is that
the code base stability aforded by those intermediate steps might be worth
the extra effort.

--brian

-- 
Brian F. G. Bidulock    � The reasonable man adapts himself to the �
bidulock@xxxxxxxxxxx    � world; the unreasonable one persists in  �
http://www.openss7.org/ � trying  to adapt the  world  to himself. �
                        � Therefore  all  progress  depends on the �
                        � unreasonable man. -- George Bernard Shaw �