| ID: | 554 |
| From: | ge...@igor2.repo.hu |
| Date: | Thu, 16 Mar 2017 11:07:44 +0100 (CET) |
| Subject: | [pcb-rnd] [dev] API fixup - trends |
| replies: | 559 from miloh <fr...@gmail.com> |
Hi fellow pcb-rnd developers and cotributors, after fixing the "load schematics to buffer" bug, I relized it's probably the best time to do the minor API cleanup in the layer group code. I'm writing about this because it'll be a trend in later cleanups and new code should consider this too. The original PCB code we inherited uses a global variable called PCB to hold the current board. It also has some other random global variables for local features. This is generally okay, we edit one board at a time. However, there are a lot of ugly workarounds in some of the code because of this. The common pattern is: 1. some code once written for manipulating the One Central PCB we have 2. later someone figured we need to temporarily work on another PCB struct 3. this resulted in workarounds that try to save the global states (the PCB variable and potentially other global variables), create a new global state, run the code in question and finally restore the old state. This is too easy to break. It's too easy to forget to save and restore, especially if a function we call calls another which then calls another and the side effect of changing a global state happens a few calls deep. The solution is rather simple: - library call should not depend on global states, but should get all states as arguments; this probably includes everything from I/O through polygons to utility functions like the layer code - the generic, main code, and UI code could still use the global vars, as we run only one instance and we don't ever need to temporary swap things there - if there are other board specific global variables, like the ones in rats.c, we should consider moving them in the PCB struct. I don't say we should start now and do this all immediately. I think I will be doing it in the background. The reason I wrote this mail is to let you know you will see more calls needing a PCB passed as first argument, and that if you write new library code and you are writing "PCB" in it, you should consider getting a pcb_board_t *pcb as first argument instead. Best regards, Igor2
Reply subtree:
554 [pcb-rnd] [dev] API fixup - trends from ge...@igor2.repo.hu
559 Re: [pcb-rnd] [dev] API fixup - trends from miloh <fr...@gmail.com>
560 Re: [pcb-rnd] [dev] API fixup - trends from ge...@igor2.repo.hu