4, 2020 1:58 PM
To: Commons Developers List
Subject: Fwd: [Geometry] Class "Equivalency"
Forwarding to ML.
Gilles
P.S. Please don't send to me directly when the post is meant for
the list, as otherwise hitting "Reply" will move the conversation
off-list...
--
om which newbies can grasp when to use which?
Thanks,
Gilles
>
> -Matt
>
> From: Gilles Sadowski
> Sent: Saturday, January 4, 2020 6:26 AM
> To: Commons Developers List
> Subject: Re: [Geometry] Class "Equivalency"
>
> Hello.
g "eq" be an overload of "equals" would to me imply
that they have the same general properties, which is not the case.
-Matt
From: Gilles Sadowski
Sent: Saturday, January 4, 2020 6:26 AM
To: Commons Developers List
Subject: Re: [Geometry] Class &qu
; WDYT?
+1
For further consolidation, could we rename "eq" to "equals", and
make "equals(Object)" call "equals(T, DoublePrecisionContext)"?
Gilles
>
> -Matt
>
> From: Gilles Sadowski
> Sent: Friday, January
ry 3, 2020 8:12 PM
To: Commons Developers List
Subject: Re: [Geometry] Class "Equivalency"
Hi.
2020-01-03 22:02 UTC+01:00, Matt Juntunen :
> Gilles,
>
> Yes, users are responsible for handling their own PrecisionContexts. The
> idea behind the Equivalency interface was to provide
h higher precision).
Gilles
>
> -Matt
> ____________
> From: Gilles Sadowski
> Sent: Friday, January 3, 2020 12:56 PM
> To: Commons Developers List
> Subject: [Geometry] Class "Equivalency"
>
> Hello.
>
> I'm wary about
Sadowski
Sent: Friday, January 3, 2020 12:56 PM
To: Commons Developers List
Subject: [Geometry] Class "Equivalency"
Hello.
I'm wary about making that class part of the public API.
I thought that the original idea was that users would be
responsible of how they handle the
Hello.
I'm wary about making that class part of the public API.
I thought that the original idea was that users would be
responsible of how they handle the "PrecisionContext".
However, it seems that "Equivalency" requires equality
of "PrecisionContext" instances (not the "double" value).
This is n
