[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/
- Re: Abstract Grob property storage into Mutable_properties. (issue 561640043 by address@hidden), (continued)
- Re: Abstract Grob property storage into Mutable_properties. (issue 561640043 by address@hidden), hanwenn, 2020/04/13
- Re: Abstract Grob property storage into Mutable_properties. (issue 561640043 by address@hidden), nine . fierce . ballads, 2020/04/13
- Re: Abstract Grob property storage into Mutable_properties. (issue 561640043 by address@hidden), hanwenn, 2020/04/13
- Re: Abstract Grob property storage into Mutable_properties. (issue 561640043 by address@hidden), nine . fierce . ballads, 2020/04/13
- Re: Abstract Grob property storage into Mutable_properties. (issue 561640043 by address@hidden), jonas . hahnfeld, 2020/04/13
- Re: Abstract Grob property storage into Mutable_properties. (issue 561640043 by address@hidden), dak, 2020/04/13
- Re: Abstract Grob property storage into Mutable_properties. (issue 561640043 by address@hidden), hanwenn, 2020/04/13
- Re: Abstract Grob property storage into Mutable_properties. (issue 561640043 by address@hidden), hanwenn, 2020/04/13
- Re: Abstract Grob property storage into Mutable_properties. (issue 561640043 by address@hidden), dak, 2020/04/13
- Re: Abstract Grob property storage into Mutable_properties. (issue 561640043 by address@hidden),
hanwenn <=