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.
_______________________________________________
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help : https://help.launchpad.net/ListHelp
