-
Notifications
You must be signed in to change notification settings - Fork 457
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
drop Cells
from function names when implicit
#451
Comments
Well, since I'm still awake and waiting on a test build, I guess I can respond now! I don't think the One thing that the regularity of the function naming buys us besides that slight increase in clarity, is that the bindings in the object-oriented languages (basically all of them) could provide an object-like API in their languages that fits better with how things work in that language, and this has been further unblocked by the new website that has language-specific docs. Imagine something like: from h3 import Cell
c = Cell('822d57fffffffff') # Returns a `Cell`
c.to_lat_lng() # Returns a `LatLng` that could be turned into a simple `[lat, lng]` or `[lng, lat]` pair
p = c.to_polygon() # Returns the outline of the cell as a `Polygon`
cs = p.to_cells() # Returns a set of cells that contains the polygon, which *should* be the original cell only
ccs = cs.compact() # Would return the same set
ucs = ccs.uncompact() # Would also return the same set The All three of the "main" bindings would be amenable to this, while the object-less C would have the functions with a regular naming so those familiar with this form should adapt decently well to working with it. Violating this regularity would make the mapping to objects in OO languages much more arbitrary and up for even more debate, which we have too much of as it is. ;) |
I don't have a strong opinion here, but one argument in favor of |
OK, so I forgot to add the example that actually kicked off this whole line of thought. It was when @nrabinowitz was pointing out that the name The following issues/PRs were me trying to come up with some consistent system that allowed for @nrabinowitz, would you say that you now prefer Also, @isaacbrodsky, you seemed to be in support of the proposal in #441, which is why I landed it at that point: #441 (review) I'm curious to hear your thoughts at this point? |
And for the record, I am won over to the side of keeping |
Chatted about this offline. I've come around to agreeing that keeping I'll close this and revert #441 . |
The conversation for #445 and #441 were a bit scattered and seem to have died, so I'm creating a fresh issue to discuss.
En Garde
The gist of the change is at #441 (comment), reproduced here:
We might consider this new "cell is assumed if omitted" rule for a few other functions:
compact
compactCells
uncompact
uncompactCells
polyfill
polygonToCells
Of those, I think
polygonToCells
is an improvement, but the compact/uncompact functions probably don't need the full specificity of "Cells", which can just be implicit. What would folks think about the following change to the RFC?compact
uncompact
polyfill
polygonToCells
Parry
@dfellis raises a valid concern that dropping
Cells
from some function names (and thus making them implicit), could be making the library less consistent:Cells
fromgridPath
,compact
,uncompact
#441 (comment)Cells
fromgridPath
,compact
,uncompact
#441 (comment)Riposte
I argue that the change maintains consistency as long as we agree that an implicit
Cells
is OK for functions where we think users can reasonably recognize the implication.polyfill
vspolygonTo<X>
remains an open question, however.Reprise
(to follow)
The text was updated successfully, but these errors were encountered: