How strictly to follow the language binding specification?

[mob41]

I am currently writing a language binding for Java. Whatever, I looked up with the existing Java language binding: https://github.com/ev3dev-lang-java/ev3dev-lang-java. The programmer does not really follow the specification as he specified the example in the README.md:

private static void backwardWithTurn(){
        mA.backward();
        mB.backward();
        Delay.msDelay(1000);
        mA.stop();
        mB.stop();
        mA.backward();
        mB.forward();
        Delay.msDelay(1000);
        mA.stop();
        mB.stop();
    }

He didn't really strictly follow with the language specification. And the functions are significantly different with the python language binding.

How strictly to follow the language binding specification? Or just make a API pointing to the classes for the developer's convenient?

[bmegli]

Hi mob41,

I believe that @jabrena follows LeJos conventions so that one can use LeJos code with ev3dev.

The language specification you mention is for ev3dev unified bindings which are ev3dev specific and consistent across languages. Also most of them are automatically generated from specification.

So putting it simply @jabrena java bindings don't fall into 'unified language binding' category but are, in a way, LeJos compatible.

Having both - LeJos compatible and ev3dev unified bindings would be great ;-)

Kind regards!

[bmegli]

@mob41 see also here:

http://www.ev3dev.org/docs/libraries/

[dlech]

IMHO, if you are following the ev3dev-lang spec, then you should call your library ev3dev-lang-<language>. If you are not using the ev3dev-lang spec, you should not be using ev3dev-lang in the name. ev3dev-lejos-compat would make more sense to me as a name for @jabrena's library if it is not implementing the ev3dev-lang api also.

[mob41]

Oh thanks. I understood more about it now.

[WasabiFan]

Fundamentally, the idea is that ev3dev-lang provides a spec for API surface area that closely follows the ev3dev driver model to give a good base "jumping-off" point for new libraries. We also have built a framework that allows a developer to implement templates for their code and then automatically generate sections of code from our spec; that makes it easy for a maintainer to keep up with kernel changes after putting in the initial effort of writing templates.

I have not looked at @jabrena's library in detail, but it boils down to this: We use the ev3dev-lang name whenever the library is an implementation or a superset of the ev3dev-lang spec. So, if he has implemented all the APIs that we define, I'd say the name qualifies; if not and the APIs are only the lejos ones, I'd say it should actually be named as @dlech explained.

If you are trying to write your library as an implementation of the ev3dev-lang spec, I'd recomend referencing the Python implementation as it is the most complete and clear.

[rhempel]

I agree fully with @dlech and @WasabiFan here - we have a standard for ev3dev-lang-* bindings, if the binding does not follow the spec, it must have a different name.