[geos-devel] GeometryPtr or ...

[Martin Davis]

Well, I don't have a strong preference on this (yet).  I do like code
brevity, though.  So would probably opt for using GeomPtr instead of
"GeometryPtr".

And yes, users do have to understand what they are doing.  And should not
run with scissors. :)  I thought perhaps defining a library typedef would
mean that user can just follow a simpler pattern without feeling they need
to grok everything about std:unique_ptr.

On Fri, Dec 7, 2018 at 9:29 AM Daniel Baston <dbaston at gmail.com> wrote:

> I don't see what it encapsulates, though...it's not as though a
> GeometryPtr is appropriate for all cases where a pointer to a geometry is
> needed, and a user can manipulate a GeometryPtr without knowledge of the
> underlying type. A GeometryPtr is only suitable in a situation where a
> unique_ptr could be used, and a user must understand this to correctly use
> a GeometryPtr. (They would also need to refer to standard library
> documentation to understand what methods are available to a GeometryPtr,
> and how they are to be used.) I guess the typedef would allow us to switch
> to some other implementation of a unique pointer without a user being
> aware, but given that unique_ptr is now in the standard library it's hard
> to imagine a situation where that would happen.
>
> Agree with Paul that consistency is probably the most important thing.
> Crude grepping shows ~700 usages of unique_ptr, ~200 usages of
> Geometry::Ptr, ~100 usages of GeometryPtr, but this misses unqualified uses
> of "Ptr" within classes that inherit from Geometry.
>
> Dan
>
> On Fri, Dec 7, 2018 at 12:08 PM Martin Davis <mtnclimb at gmail.com> wrote:
>
>> As a counter-argument, it might be better to use the typedef, based on
>> the principle of encapsulating implementation decisions.  Usual reasons:
>>
>> * Reduces comprehension complexity
>> * Makes implementation easier to change
>> * Indicates that this is an explicit design decision made in the library,
>> rather than something decided by individual developers on a case-by-case
>> basis
>>
>> On Fri, Dec 7, 2018 at 6:40 AM Daniel Baston <dbaston at gmail.com> wrote:
>>
>>> I'd agree; I find that typedefs like GeometryPtr generally obfuscate
>>> things. Although one can guess, it's not immediately obvious if GeometryPtr
>>> means Geometry*, unique_ptr<Geometry>, shared_ptr<Geometry>, or something
>>> else.
>>>
>>> Dan
>>>
>>> On Thu, Dec 6, 2018 at 5:46 PM Paul Ramsey <pramsey at cleverelephant.ca>
>>> wrote:
>>>
>>>> std::unique_ptr<Geometry> ?
>>>>
>>>> We've got a mishmash in the code base, what should it be?
>>>> As a learner arriving at the code base, std::unique_ptr<Geometry> would
>>>> have been easier, since then the semantics of the thing are more
>>>> immediately transparent then. After working with it for a while, that's
>>>> less of an issue because I've internalized the fact that GeometryPtr is a
>>>> std::unique_ptr, but still.
>>>>
>>>> The best code styleguide is a consistent code base, so deciding and
>>>> then globally changing makes the most sense, IMO.
>>>>
>>>> P.
>>>> _______________________________________________
>>>> geos-devel mailing list
>>>> geos-devel at lists.osgeo.org
>>>> https://lists.osgeo.org/mailman/listinfo/geos-devel
>>>
>>> _______________________________________________
>>> geos-devel mailing list
>>> geos-devel at lists.osgeo.org
>>> https://lists.osgeo.org/mailman/listinfo/geos-devel
>>
>> _______________________________________________
>> geos-devel mailing list
>> geos-devel at lists.osgeo.org
>> https://lists.osgeo.org/mailman/listinfo/geos-devel
>
> _______________________________________________
> geos-devel mailing list
> geos-devel at lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/geos-devel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/geos-devel/attachments/20181207/7ba5c4d6/attachment-0001.html>