kicad-developers team mailing list archive

[Wayne Stambaugh <stambaughw@xxxxxxxxxxx>]

On 4/12/2013 1:17 AM, Lorenzo Marcantonio wrote:
> On Thu, Apr 11, 2013 at 04:17:15PM -0400, Wayne Stambaugh wrote:
>
> > This isn't a bad thing unless the pointer to g_colorSettings changes.
> > It hides the fact the color settings in Pcbnew are a global variable (it
> > seems to me that they should be a member of PCB_EDIT_FRAME or one of the
> > classes it is derived from) and prevents the g_colorSettings variable
> > from littering the all the objects derived from BOARD_ITEM which I
> > believe use to be the case.  The color settings could reside and be
>
> Thanks exactly what I was asking for. It wasn't clear if colours were
> intended to be members or globals. This indirection would allow (for
> example) different colours in the module editor. If colours were (by
> design) common to the whole application then the direct global access
> would have been a better choice.
>
> > changed anywhere.  As long as the pointer to them in the BOARD object is
> > valid, all is well.  Hopefully this will discourage other developers
> > from added more globals in the future.
>
> I have nothing against globals, if the stuff is actually global. For me
> the current g_colorSettings is a good decision since colours are set at
> the application level. Putting variables in objects just because there
> should be no globals is nonsense (except in Java where you have no
> choice :D)
I don't have anything against globals when they make sense which is very 
rarely.  In the case of the color settings, they are manipulated and set 
and effectively owned by PCB_EDIT_FRAME which is probably were they 
should live.  Everywhere else, they are only read by objects to display 
the user defined color.  By making them a global variable, it allowed 
them to abused and used directly throughout the low level object code 
causing an huge mess.