underscore vs. hyphen about shared-row

[louh]

Hey all - @kfarr just pinged me over in the Streetmix Discord re: the existence of this thread, so I apologize for not seeing this earlier - e-mail is actually my preferred notification method for GitHub but they don't seem to have a setting to e-mail me for mentions. I'll try to see if there are ways I can improve this for myself but in the meantime please don't shy away from pinging me in Discord (https://strt.mx/discord) if you need my immediate attention on something.

I'm going to write some thoughts right now with the caveat that I am not thinking very thoroughly through the implications of what I'm saying because I'd rather respond quickly than respond thoroughly given the how long this conversation has remained open.

So yes, we define all of our segment types using hyphens between words and when I tried to think of a rationale for why we do it this way I don't really have a clear answer other than "because we've always done it this way." Hyphens are certainly easier to read and looks very nice (and they're great for things like file names and URLs). But they also have downsides compared to the alternatives (underscores and camelCase).

The thing is, words separated by a hyphen are not parsed as all the same token, even in JavaScript, and this is true in many other programming languages or in SQL (as mentioned already). drive_lane is one token. driveLane is one token. drive-lane parses as "drive minus lane". Hence in all situations when you need to read a string property of drive-lane you need to do something like street['drive-lane'], since street.drive-lane gets parsed as "street.drive minus lane". It is much easier on the keystrokes to write something like street.drive_lane or street.driveLane. When you're just iterating through segments or doing equality checks like we do in Streetmix we rarely really care what the actual key value is. But I can imagine a long-term wider ecosystem of this stuff where having hyphens inside of a name can be extremely annoying to a programmer.

This raises the question of whether underscores or camelCase is preferable and that seems to be highly dependent on the programming language and the standards that form around it. If I remember correctly Ruby likes underscores. Python likes underscores. JavaScript (and by extension, JSON, and thus GeoJSON) likes camelCase. At the end of the day I would say I wouldn't really have a personal preference other than "go with whatever the primary programming ecosystem prefers." In this case I might even say, do the easy thing and just keep the underscores.

Not sure if this will help make a difference either, but it's also my observation that underscore, hyphen and camelCase conversion is a very normal thing that happens all of the time:

• When we ported our database from MongoDB to PostgreSQL we named all of our columns in with underscores to follow SQL convention. Somewhere in our script we convert underscores to camelCase (and vice versa) to maintain compatibility with our old JS code.
• VueJS does a thing where you are allowed to use hyphens or camel case interchangeably. (just to clarify, we use React in Streetmix, but I happen to like Vue a lot)
• CSS requires hyphens but if you ever need to write CSS in JS you need to camelCase. Similarly, HTML attributes use hyphens but the Javascript way of accessing DOM converts those to camelCase for you.
• Lodash comes with a suite of functions that let you convert between camel, kebab (hyphen), and snake (underscore) case because it's just a thing that needs to happen a lot
• don't get me started on internationalization and country codes

My point is: given that casing is context-dependent, and there is probably a "better" choice than another depending on that context, it doesn't really make a ton of sense (to me) to specify "this is the casing Streetmix uses and everyone better use it or else."

so I've written a lot of text only to say I think the casing doesn't really matter; make the best decision for the programming ecosystem you're in, and for the best compatibility with Streetmix what really matters is that the words themselves are the same, since casing can always be converted back and forth on the fly.

with all that being said, it's probably not even a bad idea for Streetmix itself to eventually move toward the snake case so that we can avoid the issues with hyphens in code ....

[kfarr]

All make sense to me, easy to deal with on my end. Agreed on no action, will close issue

[kfarr]

From what I can discern GeoJSON appears to use camelcase: https://tools.ietf.org/html/rfc7946

[d-wasserman]

@kfarr, I can take a look at changing it. To be clear, the fix here would be to replace all "_" with "-" for slice types within the slice spec? Also, in your second comment, the property names would be camel-case? I think that only impacts sharedstreetid, and I am not opposed to that change either.

@louh, there is no downside for compatibility for using a hyphen? It might have been a change intended to enable SQL-like compatibility on my part, but I am not sure. If I don't see any objections in the next 5 days, I will make this change to the specification.

This explains some of the weirdness of the geojson exports I have tried too. Thanks for commenting.

[kfarr]

Thanks for the thoughtful comments.

To provide a bit of additional context on why I'm making this request: I am continuing to improve a "parser" that takes streetmix JSON segments and creates a 3d scene. I am also working with @dabreegster on a similar idea for abstreet and I'm hoping to standardize as much as possible by using shared-row, also to support perhaps other future services. So it's a bit self serving that I'm trying to get the standard to match streetmix as much as possible since I've already implemented that :)

So yes replacing all "_" with "-" for slice types would be great for this goal of aligning this more closely with streetmix.

(Re: My second comment, you can probably ignore it. I was just trying to research what format geojson uses to concatenate multiple words ("-" or "_" or camelcase) and it looked like camelcase, but I don't think that should change how we define slice types.)

[d-wasserman]

@kfarr - understood. We should add your project to the services section of the spec after you make progress. We want to provide examples to how the specification is being used in practice.
We should be fine with this. The concern is if those slice tags become columns in a SQL-like database, they might create issues for other user types using hyphens. That said, aligning with street-mix is a good start. We are willing to take PR if you want to have a draft change for review, but I am going to wait to give @louh time to comment if he has any thoughts on this.

[d-wasserman]

I agree with much has @louh has said. I think this is a decent case for keeping underscores.

Given that there is some intention for there to be interplay between GIS and this specification, I think we should keep underscores for now.

Thanks for bringing this up, @kfarr, but to export or use shared-row as a basis, you will have to do some odd string parsing. That said, it does not sound like a large lift. Can you share back with us how you approach the conversions if you go that route?