Open Roger-luo opened 5 years ago
This reason is not strong enough for changing the interface. Our package does not depend on Primes. I guess one can easily find mat and apply! in a package too.
Use Primes.factor
would be good enough.
I got errors when using the function factor unless I import it explicitly. It is annoying to write this extra line just because of something rarely be used.
It takes more effort to change interface in Yao.
From what I see here, you only need to remove the export, and that's all. Is there any external package depends on this? And what I mean is not export it in Yao, but it is fine to export it in YaoBlocks.
Since it admits Val type, it is not straight forward for user to get the factor if we do not export it.
Using Primes and Yao at the same time is a rare case.
OK, that sounds reasonable, I would like to keep this function then.
But I still feel strange for importing this manually especially this will be in our example. I mean, the Scale
is not part of quantum circuit anyway, we could just export it in YaoBlocks
, but do not export it in Yao
. So for users who really need to inspect the factor (which is rare as well since in most cases circuit doesn't have a Scale
).
In a hamiltonian related calculations, we have Scale
s.
The point is we can not avoid using Module.function
in julia, get used to that?
I hit this while implementing Shor algorithm.
This function conflicts with the
factor
function inPrimes.jl
, I think we don't need to export it by default forScale
, in most cases you can just usedot
. instead offactor
, after 1.0, there's no benefit to define an extra method for members anyway (since there are inspect functions likegetproperty
etc.)