I'm sure I've commented on this before but I will reiterate. I've never
liked compiling base units for each application. It seems to me that
there should be a base units object that serves at the base class for
the application specific units objects which means no more compiling the
same file 3 times to produce the correct scalars. If that is the end
goal of these changes, I'm all for it. If not, I would prefer that this
be part of the redesign. This should allow us to put the base units in
a kicad shared object.
Cheers,
Wayne
On 11/21/18 11:27 AM, Mark Roszko wrote:
Can't one just call it coordinate and child class length from it for
giggles? So at least you get both names and use the most fitting one
depending on application? Like in the case of points, you use coordinates.
> - "no operator+(point, screen_point)" is immediately understandable
I agree
>- "no operator+(vector2d<coordinate>, vector2d<screen_coordinate>)" is
>still graspable
>- "no operator+(vector2d<coord<1,0>>, vector2d<coord<0,1>>)" borders on
>confusing
That's reasonable but not what I'm arguing for?
>The latter would allow representing the zoom factor as coord<1,-1>,
This is where you lose me.
"Coordinate' means number on a single axis, this is the same as your
"length".
But your use of coord<1,-1> is a "ordered pair" and not a coordinate.
I think the issue here is semantics ;)
On Wed, Nov 21, 2018 at 11:12 AM Simon Richter <[email protected]
<mailto:[email protected]>> wrote:
Hi,
On 21.11.2018 16:24, Mark Roszko wrote:
> Shouldn't the "length" class be called "coordinate"?
> Otherwise reading point::point(length nx, length ny) as an
constructor
> is pretty weird.
Then I'd have to replicate the entire logic of "number + length unit"
for coordinates and sizes, which I thought I'd avoid and only have
"point", "vector" and possibly "size" as distinct types. With the
distinction between real-world and screen measurements, we'd be getting
close to "we need a class template" territory, but one of the minor
goals is to keep error messages readable:
- "no operator+(point, screen_point)" is immediately understandable
- "no operator+(vector2d<coordinate>, vector2d<screen_coordinate>)" is
still graspable
- "no operator+(vector2d<coord<1,0>>, vector2d<coord<0,1>>)"
borders on
confusing
The latter would allow representing the zoom factor as coord<1,-1>,
which would reduce the amount of code needed because we can have
template<int nm1, int px1, int nm2, int px2>
coord<nm1-nm2, px1-px2> operator/(coord<nm1, px1>, coord<nm2,
px2>);
and have that check units on the zoom factor, but three classes written
out would probably not be that bad either, and give us better
diagnostics.
Simon
--
Mark
_______________________________________________
Mailing list: https://launchpad.net/~kicad-developers
Post to : [email protected]
Unsubscribe : https://launchpad.net/~kicad-developers
More help : https://help.launchpad.net/ListHelp
_______________________________________________
Mailing list: https://launchpad.net/~kicad-developers
Post to : [email protected]
Unsubscribe : https://launchpad.net/~kicad-developers
More help : https://help.launchpad.net/ListHelp
