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 � [email protected] � 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 �
_______________________________________________ Mailing list: https://launchpad.net/~kicad-developers Post to : [email protected] Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
