@treeform, that's the way it's usually done, but the idea is to prevent
redundant naming for those entities that represent the same. If either the
labels or the field names can be duplicated, then the code from then forward is
cleaner and less cryptic.
Here how it works in Pascal, for the 1D,
Exactly, that was the RFC I read, I was looking for it as a post.
I would just create 26 different types and make conversions between them? There
is no need to stuff everything into a single type...
I do this with Chroma:
[https://github.com/treeform/chroma](https://github.com/treeform/chroma)
@FernandoTorres
Maybe this is the posting you had in mind:
[https://forum.nim-lang.org/t/5036](https://forum.nim-lang.org/t/5036)
The related RFC is
[https://github.com/nim-lang/RFCs/issues/19](https://github.com/nim-lang/RFCs/issues/19)
I'd like to see one of these approaches implemented.
Thanks @mashingan. My intention is to bring up a point (that popped up in an
earlier post that I can't find) in which @araq and others that I can't
remember, were talking about flexing out the restrictions, to allow duplication
of either field labels or field names, when used in the case
Another workaround
type
# The 3 notations refer to the same 3-D entity, and some coordinates are
shared
CoordinateSystem = enum
csCar, # Cartesian(x,y,z)
csCyl, # Cylindrical (r,φ,z)
csSph # Spherical(ρ,θ,φ)
workaround
import strformat
type
# The 3 notations refer to the same 3-D entity, and some coordinates are
shared
CoordinateSystem = enum
csCar, # Cartesian(x,y,z)
csCyl, # Cylindrical (r,φ,z)
csSph # Spherical(ρ,θ,φ)
This is a case in which it would be desirable that some fields in object
variants could share the name and hence, its value. In the following example,
my first two attempts: Coordinates_1 and Coordinates_2, were typed intuitively,
but failed to compile one after another due to the restrictions
