kicad-developers team mailing list archive

[Lorenzo Marcantonio <l.marcantonio@xxxxxxxxxxxx>]

On Sun, Aug 11, 2013 at 11:39:26AM -0500, Dick Hollenbeck wrote:
> Data can reside on the moon if you have accessors that hide that fact.  The interface is
> the important thing, since it is what is propagated through the client code.

Well, that's only partially true, it only hold for 1-to-1 relationships;
example: one board, two views. When grid is stored in the board, you
change the grid and both view follows.  When the grid is on the view,
each view has its grid and you simply *can't* have the grid from the
board only (which one would you get?); also the grid couldn't be
persisted, if the file represents the board.

> In the case of the grid origin *data*, it had to be moved to the BOARD because PLUGINs
> have no access to the frame, only to the BOARD, and the grid origin wanted to be saved to
> disk as part of the board file.  And BOARDs should not know about frames, so no accessor
> magic in the BOARD was possible.

These are extremely good reasons for this model. Of course the current
model has the grid tied to the board; a perfectly valid decision
would have been to tie the grid to the view (and maybe save it as user
preference). Of course, as a use case, that would be not desiderable
(especially when exchanging files:D).

Coming from a heavy database shop (stock trading in COBOL, DB2 and IMS
:D) the model drives the implementation (but the model need to satisfy
specifications). And, by the way, IMS is used because hierarchical is
faster than relational in fixed use cases:P

So, the grid can't stay on the moon, at least not until you have
specified the moon responsibilities and ensured that there is one and
only one moon for each board:D; after that, as you correctly said,
it's only a navigation thing (what you call interfaces).

> But again, the grid origin accessor is the important thing, and the code that uses it can
> use it just fine since it is in the frame.

I don't especially like these 'convenience accessor' that delegates to
related objects (i.e. if it's in the board you shouldn't call the frame
only because the frame can access them indirectly: get the board and ask
to it). However, I agree that they are... convenient. It depends how
much you like pointer chasing.

> Near term, I would vote against multiple BOARD views and how that would affect the pcbnew
> code.

That was just an example for the implications, I wasn't actively
promoting multiple views. Altough the genesis blow-up panels are pretty
cool in the screen shots, 90% of their usage would be fine with a 'list
of bookmark', anyway.

-- 
Lorenzo Marcantonio
Logos Srl