kicad-developers team mailing list archive

["Reece R. Pollack" <reece@xxxxxxx>]

It sounds like the consensus approach is to add a second parameter to 
the GetSelectMenuText() function, which will be a pointer or reference 
to an ORIGIN_TRANSFORMS object. Those implementations of this function 
that format coordinates will use this to display the coordinates 
relative to the user-selected origin.

I propose that if it is desired to move the user origin and in/mm 
selection from the user display options to the project be deferred to a 
separate patch set so this can be discussed independently.

Does this sound right to everyone?

-Reece

On 7/10/20 4:56 PM, Ian McInerney wrote:
> I view the package of information need as the arguments to the 
> function. If information isn't needed, then it shouldn't be passed in. 
> Creating a new wrapper type that just holds the EDA_UNITS and the 
> ORIGIN_TRANSFORMS object seems like an extra level of abstraction that 
> is not needed. The point of my original question about the IU is that 
> if the transform operates on the IU, then these two items are probably 
> not needed together anywhere else. Adding a struct solely to hold 
> these two datatypes will add code/understanding overhead to the 
> functions and its callsite, specifically:
> * Having to create the actual struct and populate it's fields before 
> calling the function
> * In the function the struct has to be unpacked/continually referenced 
> (so the variable names become longer)
> * It hides the fact that we are passing these two items (one of which 
> is already an opaque type) inside another opaque type when someone 
> just views the prototype for the function
>
> To me, it seems like there is not enough here to justify the creation 
> of a new layer of abstraction to pass these two items into this 
> function. If these two datatypes are needed in other places at the 
> same time, then I could see the justification.
>
> -Ian