2013/6/22 Bruno Lalande <bruno.lalande@gmail.com>

I basically agree with the propositions discussed here. Regarding the pipe-style syntax - it's just an extra layer on top of the classic syntax we've already started (view_as / make_view_as etc...) so let's first finalize it and document it, then we can discuss more in detail what a higher level syntax would look like.

My only concern is to produce unexpected and/or counterintuitive effects. "view_as<some geometry>" should always be an "exact" operation. That is, it should always return a geometry which is the exact equivalent of the input geometry (i.e. calling any algorithm on it should return the same result). For instance a 2D box can be exactly expressed in terms of a 2D polygon, a point can be exactly expressed in terms of a box (with null dimensions) so these are good uses. However, saying view_as<point>(sphere) and expecting it to return the center of the sphere is an abuse, the returned geometry is not geometrically equivalent to what we had in the first place. So that should be achieved by a more explicit call, for instance view_as_center<point>(sphere). I want to avoid obscure behaviors, basically.

I agree with this. So basically view_as<Geometry> would take coordinate_type, tag, dimension, etc. from Geometry? But not necessarily use/wrap/store/return the Geometry type?

I thought about using the same coordinate_type and dimension from the base type.

Would you prefer to have those views in geometry:: namespace? What do you think about geometry::view:: namespace? E.g.


And btw, do you think that views could be used the way I presented - to convert something into something else? Or just to access some data unavailable because of the concept limitation? E.g. only to view Sphere as it's center or box as it's min_corner?