On Wed, Feb 23, 2011 at 4:37 PM, Dane Springmeyer <[email protected]> wrote:
> Yes, we absolutely should fix up in 2.0. We've done some work already in 2.0,
> but there is more to do.
OK, here it goes (for the classes I've processed so far):
Envelope
- Add coord<T,2> overload for re_center (for consistency with all
other members)
- Don't 'intersects' and 'contains' do the same thing for points?
- Add coord<T,2> overload for init()
Feature
- To get the geometry count, one uses num_geometries. The Map
class uses xxxCount (e.g. layerCount).
- Why is props() std::map<std::string,value>, not a Parameters object?
Geometry
- num_points -> getPointCount
Map
- no removeFontSet, removeAllFontSet - inconsistent with style operations
- insert_style should be called add_style for consistency
- add remove_all_styles for consistency with Layers
- find_style returns optional, but it's not optional? The docs say
if none is found, the default one is returned.
FontSet
- 'size' is inconsistent with other 'counts'
- Return of shared_ptr from datasource_cache is inconvenient because
shared_ptr doesn't have a release(). I realize the problems with
providing release() for shared_ptr, but it does make it inconvenient
in some circumstances, especially since most mapnik functions return
references. I think it would be better to return a pointer from
create() and let the user wrap it in a shared_ptr if he wants to. Or
provide another function (create_raw?) that returns a raw pointer.
- Why does one add a style to a layer by name, and not by its pointer?
So to generalize:
- what is the capitalization standard - CamelCase or lowercase_with_underscores?
- what is the convention for getting counts of things - xxx_count,
xxx_size, num_xxx ?
- for exposed collections (not stl collections, I mean properties that
have multiple values like fonts in a fontset), shouldn't the fully
exposed API be (as far as it makes sense/is possible):
- add_xxx
- remove_xxx
- remove_all_xxx
- find_xxx
- iterator begin/end + const variants
Sorry to bring up drudgery like this :) I'll get a checkout of the
trunk too to have a look at the API there. I can write up/maintain a
style guide with the consensus on what the API should look like, as
long as someone tells me what that consensus is.
Another question: I subscribed to the mapnik-commits mailing list but
I haven't seen any mails to it for a few weeks. The trac browser shows
that there have been commits. Does it work? Did I subscribe to the
wrong one?
cheers,
roel
_______________________________________________
Mapnik-users mailing list
[email protected]
https://lists.berlios.de/mailman/listinfo/mapnik-users
