Feature request: Enums / Enumerations

[blue-ice]

I've been working on unit conversions for a certain piece of OpenSCAD code that generates springs. At the top, I have this:

units =                  [1,  10,  0.001, 25.4, 0.00328084];
  // Convert to mm from:  mm  cm   m      in    ft
  // List value:          0   1    2      3     4

// spring measurements and info
conv_units = units[3]; // inches

It's in order to be able to enter data into the code and still being able to leave it in the native units (much more helpful when you have 61/64 in and not 24.209375 mm).

However, this is sort of an ugly hack to get around the real issue. If there was an enum structure like this (notice the curly braces):

units = {mm=1, cm=10, m=0.001, in=25.4, ft=0.00328084};

Then it could be called like this:

conv_units = units[ft];

I'd love to hear feedback on the whole enumeration thing- I feel like it could be a great addition to OpenSCAD.

---

Want to back this issue? Post a bounty on it! We accept bounties via Bountysource.

[MichaelAtOz]

Basically so far, in the language, where an enum has been suggested a string has been used, like the parameters to text().

So you could do something like:

function units(unit="mm") =
    _units[ search([unit],_units,1,0)[0] ]  [1];

_units=[ 
        ["mm",1], 
        ["cm",10], 
        ["m",0.001], 
        ["in",25.4], 
        ["ft", 0.00328084]
        ];

echo(units("ft"));
echo(units("m"));
echo(units("cm"));

I think your units are not consistent (cm v's m).

[clothbot]

See also: http://en.wikibooks.org/wiki/OpenSCAD_User_Manual/The_OpenSCAD_Language#Search

[iccor56]

i sorely miss having enums. especially since variables are not exported via use command. so any module with options has to be included instead.also i really miss type safety. it would b nice to force options to a limited set of values that are defined.

[doug-moen]

@iccor56 said "variables are not exported via use command. so any module with options has to be included instead"

I think this is a bug in use, and should be fixed.

@iccor56 said "i really miss type safety"

Compile time type checking is a huge change to the language. Not sure if you are actually asking for this. Run time type safety is a more achievable goal, eg sin("foo") is an error instead of returning undef. See #1584 type test functions, #381 assert, and #1574 report error if a bad argument is passed.

@iccor56 said "it would b nice to force options to a limited set of values that are defined." That can be done using #381 assert, which is already implemented in a branch.

@blue-ice said:

units = {mm=1, cm=10, m=0.001, in=25.4, ft=0.00328084};
conv_units = units[ft];

In the OpenSCAD2 proposal, you can do this, which is almost the same:

units = {mm=1; cm=10; m=0.001; in=25.4; ft=0.00328084};
conv_units = units.ft;

[nophead]

I think you will that find variables are not imported via use by design not a bug. Neither are instantiated objects, just modules and functions.

On 18 April 2016 at 21:00, Doug Moen [email protected] wrote:

@iccor56 https://github.com/iccor56 said "variables are not exported via use command. so any module with options has to be included instead"

I think this is a bug in use, and should be fixed.

@iccor56 https://github.com/iccor56 said "i really miss type safety"

Compile time type checking is a huge change to the language. Not sure if you are actually asking for this. Run time type safety is a more achievable goal, eg sin("foo") is an error instead of returning undef. See #1584 https://github.com/openscad/openscad/issues/1584 type test functions, #381 https://github.com/openscad/openscad/issues/381 assert, and #1574 https://github.com/openscad/openscad/issues/1574 report error if a bad argument is passed.

@iccor56 https://github.com/iccor56 said "it would b nice to force options to a limited set of values that are defined." That can be done using #381 https://github.com/openscad/openscad/issues/381 assert, which is already implemented in a branch.

@blue-ice https://github.com/blue-ice said:

units = {mm=1, cm=10, m=0.001, in=25.4, ft=0.00328084}; conv_units = units[ft];

In the OpenSCAD2 proposal, you can do this, which is almost the same:

units = {mm=1; cm=10; m=0.001; in=25.4; ft=0.00328084}; conv_units = units.ft;

— You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub https://github.com/openscad/openscad/issues/1032#issuecomment-211551791

[kintel]

@doug-moen It's not a bug - it's a workaround for not having namespaces. This makes all top-level values local the the use'd file.

[jordanbrown0]

Note that there's some resemblance to objects issue #3088, PR #3087.

[jordanbrown0]

Objects as implemented in #4478 would behave almost exactly as described. (But I would think of the result as being more like constants than like enums, since there's still no type safety. There would be nothing stopping you from month = TUESDAY;.)

[DanBGold]

I know this is an old post and some things in development would work but I have a solution I have been using. Not exactly a enum but does what is needed.

mm = ["mm"]; cm = ["cm"]; m = ["m"]; ft = ["ft"]; in = ["in"]; units = [ ["mm",1], ["cm",10], ["m",0.001], ["in",25.4], ["ft",0.00328084] ]; function conv_unit(u) = units[search(u, units)[0]][1]; unit = conv_unit(ft); echo(unit);