Comments (9)
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.
Related Issues (20)
- Updating human-readable spec HOT 25
- How to create spec.json HOT 2
- How strictly to follow the language binding specification? HOT 6
- How to implement Button Class HOT 1
- How to use with the autogen system? HOT 26
- Unified language for Java - Library Submission HOT 5
- Having issue to connect Pycharm to the Brick HOT 3
- Standardize "systemDeviceNameConvention"
- Add binding for IR-SEEK to spec HOT 1
- Javascript motor and sensor example HOT 3
- A question about sensor inherits HOT 5
- 0.9.3? HOT 1
- Merge NXT Motor and Large Motor classes
- Some typo on the driver docs HOT 3
- stop lcd going back to menu HOT 2
- Dual motors HOT 2
- UNMET PEER DEPENDENCY bluebird@~3.5.0 HOT 7
- Buttons Error (platform-gpio-keys.0-event not found) HOT 3
- HiTechnic Compass Sensor "Device is not connected" HOT 3
- Status of the project - current ev3dev bindings HOT 1
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from ev3dev-lang.