On Fri, 2 Nov 2018 17:00:19 -0700, Eric Barnhill wrote:
Second question, is there any reason not to use syntactic sugar for
distinctions between "multiply" and "
multpliedBy"? With the former being the suger, if the latter is a
better
standard.
Statement needs some reference before we embark
On Fri, 2 Nov 2018 16:57:43 -0700, Eric Barnhill wrote:
On Sun, Oct 28, 2018 at 1:52 AM Stephen Colebourne
wrote:
The order of the static constants is also strange - I'm sure a more
logical order could be chosen.
I have rearranged the constants into the order 0, 1, 1/2, 1/3, 2/3,
1/4,
Second question, is there any reason not to use syntactic sugar for
distinctions between "multiply" and "
multpliedBy"? With the former being the suger, if the latter is a better
standard.
It seems like both sides of the fence can be easily bridged here.
On Fri, Nov 2, 2018 at 4:57 PM Eric
On Sun, Oct 28, 2018 at 1:52 AM Stephen Colebourne
wrote:
>
> The order of the static constants is also strange - I'm sure a more
> logical order could be chosen.
>
I have rearranged the constants into the order 0, 1, 1/2, 1/3, 2/3, 1/4,
3/4 . I propose dropping the constants
for fifths and
Hi.
On Sun, 28 Oct 2018 08:52:01 +, Stephen Colebourne wrote:
As the author of the blog and term VALJO, here are some comments on
Fraction:
Thanks for the review and comments.
You should use `of()` (overloading allowed) when the factory normally
succeeds.
You should use `from`
You are indeed and thank you very much for this feedback!
I gave up on pushing fraction through GitHub and have pushed my first round
of changes via Apache. They are available on the branch fraction-dev for
inspection. I will incorporate the rest of your suggestions on my next
iteration.
Eric
As the author of the blog and term VALJO, here are some comments on Fraction:
You should use `of()` (overloading allowed) when the factory normally succeeds.
You should use `from` (overloading allowed) when the factory methods
are performing a conversion and have a reasonable chance of failure.
On Wed, 17 Oct 2018 16:33:58 -0700, Eric Barnhill wrote:
Oh right, that is the convention. I knew there was something off.
As far as you understand, is to within VALJO standards to overload
factory
methods,
I don't think that it is ValJO-related; method overload is a
feature, so better use
Oh right, that is the convention. I knew there was something off.
As far as you understand, is to within VALJO standards to overload factory
methods, so long as they are not private constructors? All that is
specified on the page is that VALJOs must have all constructors private. So
I am not sure
On Tue, 16 Oct 2018 16:55:02 -0700, Eric Barnhill wrote:
The Fraction class is IMO looking good (in better shape than Complex
was
in) and is already quite close to fulfilling the standards for a
VALJO.
Equals() and CompareTo() are well designed and consistent. I see two
missing steps. The easy
The Fraction class is IMO looking good (in better shape than Complex was
in) and is already quite close to fulfilling the standards for a VALJO.
Equals() and CompareTo() are well designed and consistent. I see two
missing steps. The easy one is a parse() method which mirrors the
toString() method.
On Wed, 10 Oct 2018 16:18:50 -0700, Eric Barnhill wrote:
I am interested in moving forward on making the Fraction classes
VALJOs
[NUMBERS-75].
Just a preliminary question for now, are we otherwise happy with the
Fraction class in the context of commons-numbers? Or should I look
around
for any
12 matches
Mail list logo
