Purge Geometry pointer aliases?

[Daniel Baston]

I would suggest that we should only commit to stable branches for the
purpose of fixing a bug. No, we don't promise a stable API, so it may arise
that we need/want to change the API in a micro release to accomodate a
bugfix, though we still should try to avoid it (and generally have, I
think.)

Changing the API in a stable branch because our aesthetics have changed, or
because it might make it easier to backport a hypothetical bugfix, seems
like a bad idea. If I were an external user of these typedefs (
https://github.com/search?q=geom%3A%3AGeometry%3A%3APtr+NOT+is%3Afork&type=code&p=1),
or a packager of software that uses them, I would be upset that upgrading
from 3.12.2 to 3.12.3 caused them to disappear.

Dan

On Thu, Jan 9, 2025 at 6:33 PM Martin Davis <mtnclimb at gmail.com> wrote:

> There seems to be agreement that purging pointer aliases is A Good Thing
> To Do.
>
> Much of the usage in the test suite, with fewer occurrences present in the
> main code base.  So this makes it easier to clean up the main code base,
> which is the priority.
>
> Not backporting the changes may make it harder in the future to port bug
> fixes and improvements to older major versions.  We don't promise ABI
> stability for the C++ API, so I'm not sure whether this is a real concern?
>
>
> On Thu, Jan 9, 2025 at 5:52 AM Daniel Baston <dbaston at gmail.com> wrote:
>
>> Hi Martin,
>>
>> I avoid the typedefs for the same reasons you listed, but they seem to be
>> rarely used outside of unit tests (grep shows 97 lines with "Ptr" under
>> "src" and 825 lines under "tests"). I'm not sure if a purge is the highest
>> priority for improving the test suite, but am not opposed if others want to
>> take that on. I would not be in favor of backporting this type of change,
>> which would break the API in a minor release while offering no benefit to
>> users.
>>
>> Dan
>>
>> On Wed, Jan 8, 2025 at 7:16 PM Martin Davis <mtnclimb at gmail.com> wrote:
>>
>>> The GEOS codebase has several typedefs called GeometryPtr and GeomPtr.
>>> They are aliases for a mixture of Geometry * and std::unique_Ptr<Geometry>.
>>> I'm thinking it's a good thing to purge them from the codebase in favour of
>>> explicit type signatures, because:
>>>
>>> - it's highly confusing that they can be aliases for different things
>>> - it's complicated that they are defined in multiple places
>>> - it can be hard to see what they represent
>>> - they don't save much typing in the case of Geometry*, and using auto
>>> can simplify other uses
>>>
>>> This was discussed a while back.  The general feeling was that it's
>>> better to use explicit types.  Is this still the consensus?
>>>
>>> Some notes on the process:
>>> - I expect this will be done in multiple passes, to fit work schedules.
>>> Will start with the least intrusive changes
>>> - when this is done, it needs to be backported so that subsequent
>>> backports don't collide with unchanged code.
>>> - If older versions use the aliases in dead code, it may not be removed,
>>> just patched to ensure it still compiles (i.e. by leaving the typedefs in
>>> place)
>>>
>>>
>>>
>>>
>>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/geos-devel/attachments/20250109/43fd5d1d/attachment.htm>