Closed yeesian closed 8 years ago
Some lingering thoughts:
fetch
(overriding get
in some cases)
get
/set
: for heterogeneous attributes of individual itemsfetch
/update
: for collections of homogeneous itemsget
/set
from the method name when there is no corresponding set
/get
Thoughts? (See the developments at https://github.com/visr/GDAL.jl for context.)
@visr @meggart @garborg @wkearn @c42f @joa-quim @marciolegal @sboysel @tedsteiner @awbsmith @penntaylor @ljwolf
Nice list, good to get some discussion started. In general I quite like the names you propose, but I'm also thinking about some more radical ideas. Do you explicitly want to avoid extending Base functions? Since we have new types for all components I believe we can make good use of them extending Base functions without problems. What about these for example:
get___count()
/ n___()
by new methods of Base.length
.Base.getindex
instead of fetch
Base.setindex
instead of update
createlayer()
-> Layer()
What I worry about for Base.getindex
and Base.setindex
is how it makes it seem as if they are cheap operations, when in fact a lot might be happening under the hood, and I'm not sure it's behavior to be encouraged yet [1].
I think we need a good set of idiomatic (and performant) GDAL usage code before we decide what methods/behavior to encourage.
So if you find yourself needing to use the methods for fetch/update a lot, maybe you should be encouraged/prodded to read them into a buffer/array, and then to work with that buffer/array (which will have nice Base.getindex
and Base.setindex
syntax), rather than working with the thin object wrapper.
It's the same issue with rasterbands being a subtype of AbstractArray. That said, we could/should make it easy to
though. I'm going to spend more time digging through other developers' notes and trying different proposals here first.
[1]: On the other hand, my arguments above is weak if we're talking about Base.getindex
and Base.setindex
for "arrays of pointers". (so they all remain as "views", rather than concrete instantiations of in-memory values).
Replace all getcount() / n() by new methods of Base.length. [...] Replacing create___ with type constructors: createlayer() -> Layer()
I have considered them too. A concern I have is that methods might seem to be "disappearing" from the GDAL API if we make them base-methods/type-constructors.
But you're right, I think that might be more of a documentation issue, rather than an argument in syntax choice.
There's also the possibility of providing both the base-method/type-constructor, as well as the corresponding (simplified) GDAL API methods, in which case we can defer the decision on implementing base-methods/type-constructors to a separate issue.
I think the "both" is a reasonable way to go. As a general rule, I don't typically expect basemethods to be extended correctly. Specifically, I have in mind some confusion people have about generic magic methods behavior in Python GIS, where the "len" of a polyline isn't super clear on whether it's the measured length of the arc or the number of points defining its nodes.
Confusions like that, I think, make it necessary to provide the corresponding raw methods, and then (hopefully) transparently add them as methods in a reasonable way to appropriate Base.*
functions. As long as a package makes it clear how, say Base.length
might dispatch to getpointcount
or getarclength
, we're in the clear.
A rough organization into a few themes:
getcount() = n()
Examples:
Remove typenames
(rely on multi-dispatch instead) Examples:
Remove "ref"
(no pointers); Examples
Format
(Export/Import, From/To); Examples:
New Syntax
Name dropping/shortening
Examples:
instances: