Rename Point3f0 and similar to Point3f, etc.

[knuesel]

I'd like to make a case against the suffix 0 in types such as Point3f0:

• It confuses beginners (see https://discourse.julialang.org/t/makie-scatter-plot-of-vector-of-points/41039)
• It adds visual noise
• It doesn't really make sense: in the syntax 1.2f0, the f denotes Float32 and 0 is an exponent. 1.2f4 is also a Float32.
• It is unnecessarily different from what people are used to: Point3f in OpenCV, Rhino, Java vecmath, Eigen (Vector3f), probably many more.

Is there a reason to prefer Point3f0?

[pauljurczak]

As one of the beginners in questions, I fully agree. In the C++ world, you will find almost exclusively Point3f, Vector3f, etc. notation. For different element types, you will see: Point3d, Point3i, etc. The first thing I did after seeing Point3f0 was:

julia> Point3f
ERROR: UndefVarError: Point3f not defined

[SimonDanisch]

I wouldn't mind in general - but I would mind the work to refactor this and properly get rid of it in all dependencies :D

[pauljurczak]

How about an official Point3f alias?

[knuesel]

@SimonDanisch I can imagine it would be a lot of work, especially with all the dependent projects. Of course if the change is desired, it's better to do it as soon as possible. I would be happy to help with the refactoring (I could work on PRs in the coming weeks if there's interest).

@pauljurczak I'd rather not have both, it introduces another kind of confusion. But I guess we would have an alias during a deprecation period.

[jkrumbiegel]

I would mind the work to refactor this and properly get rid of it in all dependencies :D

I can't imagine this would be so much work, after all, it's a prime candidate for a simple search and replace, no? Of course tagging the versions would be a bit of work. I like the idea of a rename, especially because we would match the conventional naming, and we should do things like this earlier rather than later.

[SimonDanisch]

Yeah, its not a crazy amount! I mainly meant to say, that I won't do it in the little time i have, but if someone is willing to, they're free to open a PR to the dependent packages :)

[asinghvi17]

I think a depwarn release of GeometryBasics + a replace in dependent packages should be sufficient. Here's the list of all (direct and indirect) dependent packages:

AbstractPlotting
Arena
AugmentedGaussianProcesses
CairoMakie
CatmullClark
ComplexPhasePortrait
ConstrainedDynamics
ConstrainedDynamicsVis
DrakeVisualizer
GLMakie
GeoMakie
ImplicitPlots
InteractiveChaos
Makie
MakieGallery
MakieLayout
MakieThemes
MechanismGeometries
MeshCatMechanisms
MicroscopyLabels
PredictMDExtra
PredictMDFull
RigidBodyTreeInspector
StatsMakie
TrajectoryOptimization
WGLMakie

(from JuliaHub)

[knuesel]

@jkrumbiegel it would take a bit more care at least in GeometryBasics since the type names are macro-generated, but that might make it even easier... So yeah I guess most of the work would be in filing PRs for the different packages. I think I could do it some time this month.

[knuesel]

(Oops I was a bit fast, it's not merged yet.)