search

opening-hours / opening_hours.js

Library to parse and process the opening_hours tag from OpenStreetMap data
https://openingh.ypid.de/evaluation_tool/
222 stars 118 forks source link

Properly rewrite library in $language. Rust? #136

Open ypid opened 8 years ago

ypid commented 8 years ago

To take this library to the next level, I checked out ways to port it to other platforms/programming languages. Some effort has already been made for the following platforms/languages: Bindings and ports and Other implementations

I played a bit with Haxe and rewrote a small script in it: https://github.com/ypid/opening_hours.js/blob/master/Gen_taginfo_json.hx

Rewriting the library in Haxe will take an enormous effort. Also because some of its dependencies will have to be ported to Haxe. Most importantly suncalc. Other dependencies can be left unattended for now (JavaScript is still the main target for this library). Testing will still be done mainly against the JS transcompiled target to ensure that it still works. Minor unit tests will also be done against Haxe and every other target.

Rewriting the library in Haxe will allow to easily target Java, JavaScript, PHP, Python and C++ natively by transcompiling code for those targets and then build/publishing those generated libraries.

During the rewrite, a change to a proper Lexer/Parse compiler generator will be evaluated more closely to avoid all the hand-written Lexer/Parser code. Not sure if this will make it easier or more difficult. It will need to be tested. Ref: https://code.google.com/p/hxbison/ and https://github.com/Simn/hxparse

@simonpoole: You recently worked on porting the library/specification to native Java. What do you think about this idea which would allow us to put our forces together?

I know that this is more of an long term issue so don’t expect the rewrite/target libs to be ready anytime soon.

Note: It will not be possible to inline public API functions using Haxe because this would violate the LGPL which the Haxe port is going to be released under.

Status:

cc: @ramsestom, you might be interested (but this is long term). Ref: https://github.com/simonpoole/OpeningHoursParser/issues/10

amenk commented 8 years ago

Actually I use the lib in both JS and PHP. For PHP I just call nodeJS via a small CLI wrapper.

ypid commented 8 years ago

@amenk Interesting. And how do you access the API in PHP? I kind of know that this is totally overengineering, but I still want to try it.

amenk commented 8 years ago

I don't... The logic is in A small CLI JS script which I call from PHP...

ypid commented 8 years ago

Sure, you can do that … But me as a good library maintainer, I want to provide native access :wink: At least long term. Your current approach also means massive overhead because of the startup of Node.JS and oh.js for each oh value? I wrote a wrapper for Python which kind of works similar: https://github.com/opening-hours/pyopening_hours (but without the startup overhead for each new call).

ypid commented 8 years ago

Made some progress by porting the SunCalc library to Haxe: https://github.com/ypid/suncalc

The only thing I am a bit concerned for porting opening_hours.js to Haxe is the limited Date support in the standard library in Haxe currently (so I will checkout DateTime more closely).

ypid commented 4 years ago

I am more in favor of rewriting in Rust. But that is not something I am going to dedicate time to over the next years. So this issue truly is a long-term one unless someone else picks it up :)

Lee-Carre commented 2 years ago

Title: s/Proerly/Properly/ 🙂