do not export factor?

[Roger-luo]

I hit this while implementing Shor algorithm.

This function conflicts with the factor function in Primes.jl, I think we don't need to export it by default for Scale, in most cases you can just use dot. instead of factor, after 1.0, there's no benefit to define an extra method for members anyway (since there are inspect functions like getproperty etc.)

[GiggleLiu]

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.

[GiggleLiu]

Use Primes.factor would be good enough.

[Roger-luo]

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.

[GiggleLiu]

It takes more effort to change interface in Yao.

[Roger-luo]

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.

[GiggleLiu]

Since it admits Val type, it is not straight forward for user to get the factor if we do not export it.

[GiggleLiu]

Using Primes and Yao at the same time is a rare case.

[Roger-luo]

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).

[GiggleLiu]

In a hamiltonian related calculations, we have Scales.

The point is we can not avoid using Module.function in julia, get used to that?