kicad-developers team mailing list archive

[Dick Hollenbeck <dick@xxxxxxxxxxx>]

On 11/24/2011 03:01 PM, Vladimir Uryvaev wrote:
> At Tuesday 22 of November 2011 22:26:23 from Brian F. G. Bidulock:
>> Why one or two fields?  This makes for unnecessary work.
>>
>> Why not them all?  You see, the easiest way to do this is t
>> just make all the fields private and then use the compiler
>> to identify everywhere that contract is broken, change each
>> occurrence to use an accessor, and they you're done.  There
>> should be absolutely no change in behaviour unless there is
>> a compiler bug.  At least that's what I did over a year ago.
>
> 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.
My favorites:

- conditional breakpoints for debugging.
- debug logging of changes, which are trapped at a single code site.
- control over the conversion (rounding) from an alternate type, such as double or "long
double".

What I don't like about them is the mindless use of the words set???() and get???().  
Sometimes I prefer the

.x() and .x( aValue )

notation that you had used. 

I would have kept your accessors if I could have done it easily without the TO_LEGACY_LU()
stuff.

I found no easy way to retain that code.

One area I can contribute most quickly is in the load and save code.  This is just a heads
up before I get the plan out.

The boost::polygon stuff does use a lot of templates, and it is hard to read.  But the
bottom line on their strategy is what we need to take away:

1) All intermediate products and quotients involving BIUs are in either double or "long
double".
2) A consistent rounding strategy back to the integer domain needs to be used.
3) We do not have to copy our polygons into their format, we can teach boost how to access
our polygons directly.

I would not want to expose our code to their headers more than necessary, because of
templates, which get very hard to debug and understand.

Dick





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