Could you remove the final keyword from your BigDecimal, BigInteger and BigRational classes? about math

[BenMorel]

Because the API is not fully stabilized yet, I prefer to keep extensibility to a minimum to avoid breaking too much stuff when changing internals. But I would definitely be interested by your use case for extensibility!

About dependency injection, you usually inject services, but not value objects? Why would you ever dependency-inject a BigInteger? Again, I'm interested by the use case, in case I'm missing something.

A technical note about private constructors.

Private constructors and public factory methods is a strategy I use to speed up object creation. Basically, the private constructor assumes that the input is fully validated, and just copies the information to the private fields. The public factory methods, called by your application, perform the necessary checks and conversions before calling the constructor.

The advantage here is that the methods such as plus(), minus() which all return a new object, can directly call the private constructor, as we know for a fact that they output valid information.

If we were to validate things in the constructor, there would be unnecessary validation here, and performance would be affected.

[ivands]

Thanks of the response.
I wanted to use ur BigInteger & BigDecimal classes but i don't really like
the method names your using.
And my application is already dependent on a Number & Money interface.
So I wanted to extent ur BigDecimal class and add some alias methods to it.

Ur argument for not using dependency injection on ur BigDecimal class is
valid.
But this isn't necessarily the case for my ideal Money class.
I would like to add some service classes to the money object.
To make the Api more easy to use.
Right now its completely impossible to extend your classes or add my own
dependencies.

Side note I'm aware your money class is a value object.
And maybe i shouldn't be adding dependencies to it.
But this is just a special use care i have.

2015-09-05 14:29 GMT+02:00 Benjamin Morel [email protected]:

Because the API is not fully stabilized yet, I prefer to keep
extensibility to a minimum to avoid breaking too much stuff when changing
internals. But I would definitely be interested by your use case for
extensibility!

About dependency injection, you usually inject services, but not value
objects? Why would you ever dependency-inject a BigInteger? Again, I'm
interested by the use case, in case I'm missing something.

A technical note about private constructors.

Private constructors and public factory methods is a strategy I use to
speed up object creation. Basically, the private constructor assumes that
the input is fully validated, and just copies the information to the
private fields. The public factory methods, called by your application,
perform the necessary checks and conversions before calling the constructor.

The advantage here is that the methods such as plus(), minus() which all
return a new object, can directly call the private constructor, as we know
for a fact that they output valid information.

If we were to validate things in the constructor, there would be
unnecessary validation here, and performance would be affected.

—
Reply to this email directly or view it on GitHub
#2 (comment).

[JanTvrdik]

But one of my use cases requires me to have extendability

Could you elaborate on why you need to extend those classes? Have you considered extending BigNumber and wrapping e.g. BigInteger instead of extending it?

[jkuchar]

What you are searching for is object composition: https://en.m.wikipedia.org/wiki/Object_composition

[BenMorel]

@jkuchar is right, if you don't like the API, you can use composition instead of inheritance and create your own API on top of it.

That's what I've done with brick/phonenumber, that's based on giggsey/libphonenumber-for-php, for example: I didn't like the fact that the original PhoneNumber implementation was mutable, and a few other things, so I've composed my own PhoneNumber implementation on top of it.

You're welcome to do the same here!