kicad-developers team mailing list archive

[Lorenzo Marcantonio <l.marcantonio@xxxxxxxxxxxx>]

On Sat, Apr 04, 2015 at 01:36:31AM +0200, Simon Richter wrote:
> 1. Replace bitmask with enumeration of all valid values
> 
> Only a few of the values possible were actually sensibly supported anyway,
> so this can be simplified by replacing the various integer representations
> with a single enumeration.

Agree with that. Of course you can say that the bit in the enumeration
value have the current meaning :P i.e. you can use magic enumerated
value.

> 2. Keep strings/bitmaps outside of LIB_PIN
> 
> These are UI elements.

Also, AFAIK the bitmaps are only used in the pin dialog...

> 3. Keep load/save outside of LIB_PIN
> 
> These belong to the load/save routines, which may change when switching to
> s-expressions.

*Could* be contested, depending on the OO school you follow:

- You can say that serializing is responsibily of the pin (i.e.
  virtual methods)
- You can say that the load/save is/has/uses (we could discuss days on
  this detail alone...) a pin factory (for load) and a pin user (for
  save)
- You could even say that there is an independant pin adaptor object which
  handles the translation.

Since the things are orthogonal and C++ has only single type dispatching
there is no 'optimum' solution for that. The procedural way would be
having the i/o routines filling the pin (i.e. option 2 above). Given
that I/O is involved the functional way would be probably a mess:D

> 4. Introduce dedicated ComboBox for pin shapes
> 
> This makes the pin shape selection widget reusable across different
> dialogs, and removes the responsibility of the user to initialize the
> available selections.

Is there more than one dialog using these? Anyway it could be said
that's a quite easy to do refactoring of the code.

Also: pin type is more or less useless (like the related DRC), so
I wouldn't worry too much about it.

-- 
Lorenzo Marcantonio
Logos Srl

Attachment: smime.p7s
Description: S/MIME cryptographic signature