Boost logo

Geometry :

Subject: [ggl] namespace model::
From: Simonson, Lucanus J (lucanus.j.simonson)
Date: 2010-12-01 14:39:06


Barend,

I agree with Bruno, you should not need namespaces at all. Let the user define their own convenient typedefs in their own namespaces and move these convenience typedefs out of the library entirely and into the example code. I find my Polygon users take my example code which includes namespace aliases and convenient typedefs for template classes and copy/paste it as the starting point for their own usage of the library. They aren't suffering from lack of convenient typedefs provided by the library itself.

Regards,
Luke

________________________________
From: ggl-bounces_at_[hidden] [mailto:ggl-bounces_at_[hidden]] On Behalf Of Bruno Lalande
Sent: Wednesday, December 01, 2010 10:40 AM
To: Generic Geometry Library Discussion
Subject: Re: [ggl] namespace model::

Hi Barend,

I would put the convenience classes (_xy, _ll) in the same namespace as their "less convenient" counterparts, that is:

The reason for existance of point_xy is that it provides the additional methods x(), y(), and a constructor taking two values. I don't use them. The library does not use them (besides in examples and some tests).

If it's so specific, let's not create a special namespace for it, and we don't even have to make the effort of aligning its name with other points:
point_2d => 2d::point
point_xy => 2d::point_xy

(same for 3d)

But some library users might appreciate it. But actually I find the xy::point namespace a bit funny. There are no (or not yet) other geometries with _xy, like linestring_xy / xy::linestring or polygon_xy / xy::polygon (though for consistent with d2:: they might be created).

Why should we force ourselves to create polygon_xy and so on just because the 2d namespace contains all those. Not creating them at all is another reason for simply putting point_xy in the 2d namespace and not create any other namespace.

The reason for existance of point_ll_deg is that it provides the additional methods lat(), lon(), and a constructor taking a special provision that lat and lon might be specified in any order. The library does not use them. It is designed some years ago, and because lat/lon is always confusing (y/x), it made some sense. However, I'm not sure about things like model::ll::degree. By the way, this latlong point is all in an extension.

I think we shouldn't try to push convenience too far here, or we will basically reproduce all the combination that template can produce with namespaces, which defeats the purpose of templates. Why not simply have a template class ll::point that lets the user define the unit to use as template parameter? It provides the "first level" of convenience from the general point class, which is sufficient I think.

Does my approach make sense?

Regards
Bruno
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.osgeo.org/pipermail/ggl/attachments/20101201/98229686/attachment.html


Geometry list run by mateusz at loskot.net