Add more intuitive edge names

[adrianVmariano]

I've noticed that you generally seem to favor what I think of as excessive verbosity in naming, but in the case of the EDGE* constants, instead I find a bunch of cryptic abbreviations that I don't seem to be able to remember. Is front FT? I know it's two letters....but no, that is an error? I don't know.... For me the abbreviations end up being read-only, in the sense that I know what they mean when I see them...but I can't remember them. So I'm suggesting adding full spelled out versions.

Another thing: I would like the wiki documentation to list the constants rather than just referring to constants.scad (with no hyperlink). So for example, when cuboid says to use the edge constants you should list them right there, I think. Even if this ends up being a little repetitive in the manual, it will make it easier to use.

Maybe it's possible to define all of the edge constants without actually having to state them all by explaining the system of it?

[sej7278]

got to agree, i keep having to refer to constants.scad as i can't remember when something is LF or LEFT, BOT or BOTTOM; is FR front or front-right? can we just stick with full names e.g. EDGES_BACK_LEFT?

[revarbat]

I can expand the names of all the edges. TOP, BOTTOM, FRONT, BACK, LEFT, RIGHT. Would it be preferable to name them like TOP_LEFT instead of EDGE_TOP_LEFT?

[revarbat]

I've already renamed all the V_ directional vectors to not have the V_ prefix. (V_UP → UP)

My only wariness on this is that UP+LEFT would not be the same as TOP_LEFT, which would be an edges array.

[sej7278]

yes i can't see how we can remove the EDGE/EDGES prefix

[adrianVmariano]

It seems like (for example) EDGES_LEFT can't be renamed to LEFT. I guess that's the disadvantage of using variables instead of text strings. One way around would be to use text strings and then map them to the contextually appropriate arrays.

I have no problems with BOT as an abbreviation, but for consistency I suppose best to spell everything out. I suppose another advantage of text strings is that it would be possible to support a variety of abbreviations.

[adrianVmariano]

I suppose another advantage of doing a text string solution is that it could handle multiple additions/subtractions in an intuitive fashion.

[adrianVmariano]

Here's another thought that would be less work to implement: take a list of parameters. The different strings like TOP, BOTTOM, UP, etc would have arbitrary values and a list of them would be mapped to the contextually appropriate vector. So edges=[TOP,BOTTOM], or edges = [ALL, -TOP]. And then boolean operations rather than sums can be used to combine them so that there are no surprises. This is a little less flexible than the text string idea.

I suppose a downside of all of these ideas is that maybe the user wants to just give the edge or direction vector directly. I guess you could check for that case by making sure that all the constants have large values that don't look like proper edge or direction vectors.