Re: Abstract Grob property storage into Mutable_properties. (issue 561640043 by address@hidden)

[Dan Eble]

On Apr 13, 2020, at 16:31, address@hidden wrote:
> 
>> Does const serve a purpose here?  The iterator doesn't carry through
> with any
>> kind of enforcement.  The same question applies to try_retrieve() and
>> to_alist().
> 
> It allows one to iterate over properties in a const method.
> 
> What kind of enforcement are you looking for?

There's a tension between C++ and Scheme structures that I struggle with.  In 
C++, a const method usually doesn't change the externally observable state of 
its object, and *usually* avoids returning a non-const reference to a component 
part, so as not to open a way for the caller to mutate the object.

If this const method is not enforcing these things because SCM data structures 
have no constness, then what is the value in declaring it const?  You've said 
that you're declaring it const so that it can be called from a const method. 
Granting that the caller may be const for a good reason, the suggestion that a 
Mutable_properties object will not be changed by a caller that calls 
properties.to_alist() is misleading.

I think it would be better to declare methods as const where it agrees with 
reality, e.g. contains().  That way you can meaningfully pass a const Whatever& 
around and trust that the recipient can not change its state.  I would do this 
even if the consequence is that passing a const Whatever& is not useful at 
present.

In the case that concerns you--iterating the SCM list in a const method of a 
class that owns a Mutable_properties object—I think I would declare the 
Mutable_properties object as mutable.  That way, all the owner's methods can do 
as they please with the owned Mutable_properties, consistent with its nature as 
primarily a SCM structure.

In short, that way "const" means const, and "mutable" means mutable.
— 
Dan