kicad-developers team mailing list archive

[Laurent GONZALEZ <kicad@xxxxxxxxxx>]

On 27/02/2012 15:03, Dick Hollenbeck wrote:
> 
> 
>>> I propose to start with getting rid of that mess, and see later whether
>>> we want to introduce more flexible scheme, maybe that would give
>>> priority to pin name, or location in the drawing.
>> It is on my personal to do list at some point in the future.  As an
>> interim step, you could use GetNumberString() and sort using the string
>> instead of the long integer value of the m_number member variable.
> 
> We can and should also think about getting "rid of messes" by *hiding* them behind a
> elegant public interfaces.
> 
> Client code is where you replicate the calling into the public interfaces, and only that
> *replication* would determine if a mess is being made or not.
> 
> If awkward implementation details are kept in a single place, hidden behind a public
> interface, the awkwardness is not important.
> 
> See what I did to the same design of PADs in PCBNEW.  There is a "long" used there to hold
> the 4 character pad number.  But nobody knows this, it is hidden.  So changing strategies
> is trivial, since you did not replicate the strategy.
> 

I wholeheartedly agree with you.

The case I highlighted, breaks down to decide whether ASCII files
holding library data (and others) belong to the interface or not. No
wonder, that my opinion is "yes they do", hence my suggestion to sort
pins in a useful way (some indentation may help as well).

I apologize if somebody has been hurt by my messy words, I do not master
all the nuances of Shakespeare's language :)

--
Laurent