[cpp] Getting rid of string constants in public API

[ddemidov]

I'd like to get rid of hard coded string constants like these.

• First, I think writing the strings directly is more clear and concise. Compare this:

irsens.set_mode(ev3dev::infrared_sensor::mode_proximity);

to this:

irsens.set_mode("IR-PROX");

In case of python possible string values are easily checked in interactive python shell:

>>> irsens.modes
['IR-CAL', 'IR-PROX', 'IR-REM-A', 'IR-REMOTE', 'IR-S-ALT', 'IR-SEEK']
>>> irsens.mode = 'IR-REMOTE'

• Second, the constants tend to obsolete. For example, the specific strings I linked to above are no longer applicable since the latest overhaul of taho-motor class.
• And third, I believe the false feeling that user is protected by the compiler when the strings are hard-coded is false. For example, the compiler won't stop me from

irsens.set_mode(ev3dev::motor::position_mode_absolute);

So I'd like to get rid of most of the strings constants at least in public API. What do you think?

CC @fdetro.

[ddemidov]

On the other hand, having the constants around makes it possible to change the code in one place in case a constant value changes. So I am open to discussion.

[WasabiFan]

I'd support removing them. I think the constants are more work to maintain than they're worth: The variable name contains the contents of the string in most cases, so there isn't any abstraction included. If the user wants this type of constant, they can declare their own that is specific to their application and provides abstraction.

[dsharlet]

The hardcoded string constants are findable via IDE completion
(intellisense, etc.), while hard coded strings are not. I think this is
significant, 90%+ of my "documentation" lookup is done with autocompletion
of code.

As for the python interface, I'm sure its easy to use but I've never even
touched it. It also seems like it would require actually having an ev3dev
instance running with the device you are trying to program plugged in to
use it, which is an unnecessary and unintuitive constraint.

I think the last problem (type safety) needs to be solved by using an enum,
which is strongly typed (at least more than strings).

On Tue, May 5, 2015 at 2:51 PM Wasabi Fan notifications@github.com wrote:

I'd support removing them. I think the constants are more work to maintain
than they're worth: The variable name contains the contents of the string
in most cases, so there isn't any abstraction included. If the user wants
this type of constant, they can declare their own that is specific to their
application and provides abstraction.

—
Reply to this email directly or view it on GitHub
#67 (comment).

[WasabiFan]

The hardcoded string constants are findable via IDE completion
(intellisense, etc.)

That's a good point that I didn't consider. Maybe we should just shift this constant system that's currently in there over to a full enum?

[ddemidov]

I agree with @dsharlet's point about IDEs (I overlooked this since my IDE of choice is vim :) ).

The problem with enums is that the system then becomes too strong and does not allow any deviations. For example, #57 was solved by supplying custom port name ("in3:sv1") to a servo motor constructor. It would be impossible if we restricted ports to the current four values of INPUT_[1-4]. There could be other examples where such flexibility is required. In fact, the library in its current state would be unusable with strict enum system, since the constant system is a bit outdated.

So I am thinking of leaving the constants as strings for documentation purposes, and updating them for the current kernel. By the way, this could be easily done if we had possible values stored in autogen/spec.json. @WasabiFan, what do you think about this?

[WasabiFan]

By the way, this could be easily done if we had possible values stored in autogen/spec.json . @WasabiFan, what do you think about this?

If you are looking to create a template file for whole lines of code like we already do with our getters/setters (meaning it doesn't require any extra functionality in the script) and are just looking to include this info in the spec, go for it -- I'm not quite sure what specific strings you want, but if you are willing to find a structure to support holding these strings in the JSON I'm fine with it.

[ddemidov]

I am thinking of adding a nested lists of possible values to each of the properties. E.g.

{
  "name": "Command",
  "systemName": "command",
  "type": "string",
  "readAccess": false,
  "writeAccess": true,
  "values" : ["run-timed", "run-to-rel-pos", "run-to-abs-pos"]
},

Each value should translate to a string constant in the code:

static const std::string command_run_timed = "run-timed";
...

The question is, would it be possible to loop over the values list in the liquid file?

[ddemidov]

I think this is definitely possible. I'll try to propose a PR in the coming days.

[ddemidov]

Resolved by #69