lilypond-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Abstract Grob property storage into Mutable_properties. (issue 56164


From: hanwenn
Subject: Re: Abstract Grob property storage into Mutable_properties. (issue 561640043 by address@hidden)
Date: Fri, 17 Apr 2020 12:17:01 -0700

On 2020/04/13 22:10:25, dan_faithful.be wrote:
> On Apr 13, 2020, at 16:31, mailto: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.

I view const more as a structured comment than an enforcing mechanism.
If we would 
take a strict stance, I think we would have to delete most of the const
keywords,
and that would actually increase the chances of developers misusing the
APIs.


https://codereview.appspot.com/561640043/



reply via email to

[Prev in Thread] Current Thread [Next in Thread]