[cpp] Getting rid of string constants in public API about ev3dev-lang HOT 9 CLOSED

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.

from ev3dev-lang.

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.

from ev3dev-lang.

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 [email protected] 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).

from ev3dev-lang.

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?

from ev3dev-lang.

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?

from ev3dev-lang.

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.

from ev3dev-lang.

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?

from ev3dev-lang.

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

from ev3dev-lang.

Resolved by #69

from ev3dev-lang.