Some notes about the implementation. I'm aware of this part of the README:
I represented it this way because even though so far I've only implemented some of the functionality, I think it makes sense conceptually to want to look up trips by route_id and/or service_id, and to look up stop_times by trip_id and/or stop_id. So rather than just storing the data as a hashmap, I figured it was better to store the data as a big list, and have various handles into it.
However, on the JVM we can use object references, and thus use as many maps as we need indexes, it's not like we would duplicate the data multiple times, so there is no need to store indices in the maps and keep the lists. The indirection is already what happens behind the scenes when accessing an object from the heap. This is why I directly build the maps at parsing time, and thus at request time the access to the data is very fast.
About Gradle files
Gradle is the build system used to build the Kotlin project. It has the concept of Gradle Wrapper which means storing a few files (gradlew, gradlew.bat, gradle/wrapper/*) so Gradle can automatically be downloaded in the correct version. Don't get scared by these files :)
Some notes about the implementation. I'm aware of this part of the README:
However, on the JVM we can use object references, and thus use as many maps as we need indexes, it's not like we would duplicate the data multiple times, so there is no need to store indices in the maps and keep the lists. The indirection is already what happens behind the scenes when accessing an object from the heap. This is why I directly build the maps at parsing time, and thus at request time the access to the data is very fast.
About Gradle files
Gradle is the build system used to build the Kotlin project. It has the concept of Gradle Wrapper which means storing a few files (
gradlew,gradlew.bat,gradle/wrapper/*) so Gradle can automatically be downloaded in the correct version. Don't get scared by these files :)