kicad-developers team mailing list archive

[Vladimir Uryvaev <vovanius@xxxxx>]

At Friday 25 of November 2011 02:38:47 from Brian F. G. Bidulock:
> 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.

Interface is somewhat theoretic feature. Interface means that several classes 
provide same set of methods for some purposes (e. g. arraya and map use [] to 
access individual elements).

> 
> 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.

We have taken a thought, and so there a blueprint to write, as we now have an 
idea on efficient container for spacial data.

> 
> 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.

Is there an advantage? How the stability could aford with this step?

> 
> --brian

-- 

--- KeyFP: DC07 D4C3 BB33 E596 CF5E  CEF9 D4E3 B618 65BA 2B61