wxTopLevelWindow::GeometrySerializer::SaveField() const

[wsu]

I am trying to create a concrete class that implements the wxTopLevelWindow::GeometrySerializer() interface, but I have run into a problem:  The wxTopLevelWindow::GeometrySerializer::SaveField() function is declared const, and the  wxTopLevelWindow::GeometrySerializer::RestoreField() function is declared non-const.  This looks backwards to me.  I expect SaveField() to write data into the backing store, and RestoreField() to read data from the backing store.

The non-const RestoreField() seems unnecessarily permissive, but doesn't actually hurt me.  However, the const SaveField() is forcing me to declare my backing store mutable, which I consider a "code smell".

Am I misunderstanding how the interface is intended to be used?  If not, is it too late to make the non-backwards-compatible change of reversing the const declarations?

[Vadim Zeitlin]

On Sun, 14 Jun 2026 13:35:17 -0700 (PDT) 'wsu' via wx-dev wrote:

w> I am trying to create a concrete class that implements the
w> wxTopLevelWindow::GeometrySerializer() interface, but I have run into a
w> problem: The wxTopLevelWindow::GeometrySerializer::SaveField() function is
w> declared const, and the
w> wxTopLevelWindow::GeometrySerializer::RestoreField() function is declared
w> non-const. This looks backwards to me. I expect SaveField() to write data
w> into the backing store, and RestoreField() to read data from the backing
w> store.

Yes, this is a mistake :-( I must have been thinking about const-ness at
the level of the TLW whose geometry is being saved/restored, but this is,
of course, irrelevant from GeometrySerializer-derived class point of view.

w> Am I misunderstanding how the interface is intended to be used? If not, is
w> it too late to make the non-backwards-compatible change of reversing the
w> const declarations?

I think we can risk changing this (in 3.3 only, of course) because this
class is relatively new and a code search doesn't find a lot of its users
(but someone had already run into this problem but just left a not very
flattering comment in their code instead of/without reporting the bug).
Alternative would be to deprecate {Save,Restore}Field() functions and add
some new {Save,Restore}Value() with proper const-ness forwarding to the old
functions by default for compatibility, but this would be

1. Ugly
2. New functions wouldn't be pure virtual

so it doesn't look like a good idea.

But wait, maybe we could entirely deprecate GeometrySerializer instead and
add a new class with the correct semantics? I think this would work nicely,
although we'd still need to change the function names too. Does anybody
have a nice name for the new class? GeometryStore maybe? GeometryPersistor?

Thanks,
VZ

[wsu]

On Sunday, June 14, 2026 at 6:53:41 PM UTC-4 Vadim Zeitlin wrote:

I think we can risk changing this (in 3.3 only, of course) because this
class is relatively new and a code search doesn't find a lot of its users
(but someone had already run into this problem but just left a not very
flattering comment in their code instead of/without reporting the bug).
Alternative would be to deprecate {Save,Restore}Field() functions and add
some new {Save,Restore}Value() with proper const-ness forwarding to the old
functions by default for compatibility, but this would be

1. Ugly
2. New functions wouldn't be pure virtual

so it doesn't look like a good idea.

But wait, maybe we could entirely deprecate GeometrySerializer instead and
add a new class with the correct semantics? I think this would work nicely,
although we'd still need to change the function names too. Does anybody
have a nice name for the new class? GeometryStore maybe? GeometryPersistor?

 

I suggest GeometrySerializerV2.  I think it's harder to immediately understand the difference between GeometrySerializer and GeometryStore than to understand the difference between GeometrySerializer and GeometrySerializerV2.

[Vadim Zeitlin]

On Sun, 14 Jun 2026 17:20:01 -0700 (PDT) 'wsu' via wx-dev wrote:

w> I suggest GeometrySerializerV2.

Sorry, I strongly dislike this Microsoft convention and I think it's
especially inappropriate in this case because the new class will be used as
a _base_ class for GeometrySerializer, whereas you'd expect
GeometrySerializerV2 to derive from GeometrySerializer.

w> I think it's harder to immediately understand the difference between
w> GeometrySerializer and GeometryStore than to understand the difference
w> between GeometrySerializer and GeometrySerializerV2.

My intention is to deprecate GeometrySerializer with a message telling
people to use GeometryWhatever instead, so this should help with this.

Regards,
VZ

[Vadim Zeitlin]

Hello,

I went ahead and implemented my proposal in

https://github.com/wxWidgets/wxWidgets/pull/26602

Please let me know if you see any problems with it.

Thanks,
VZ

[wsu]

I'm afraid I have been busy, and may continue to be for a while.  I don't know how quickly I will be able to get to this.

[Vadim Zeitlin]

On Thu, 18 Jun 2026 19:21:00 -0700 (PDT) 'wsu' via wx-dev wrote:

w> I'm afraid I have been busy, and may continue to be for a while. I don't
w> know how quickly I will be able to get to this.

I've merged it for now, but it would still be great if you could confirm
that it works before 3.3.3 (in a couple of weeks).

Thanks,
VZ

[wsu]

On Friday, June 19, 2026 at 11:17:37 AM UTC-4 Vadim Zeitlin wrote:

I've merged it for now, but it would still be great if you could confirm
that it works before 3.3.3 (in a couple of weeks).

I have confirmed that this works.