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

[dak]

On 2020/04/13 20:27:34, hanwenn wrote:
> On 2020/04/13 20:10:35, dak wrote:
> >
>
https://codereview.appspot.com/561640043/diff/565900043/lily/include/mutable-properties.hh
> > File lily/include/mutable-properties.hh (right):
> > 
> >
>
https://codereview.appspot.com/561640043/diff/565900043/lily/include/mutable-properties.hh#newcode31
> > lily/include/mutable-properties.hh:31: class Iterator {
> > On 2020/04/13 17:22:52, hanwenn wrote:
> > > On 2020/04/13 17:15:19, Dan Eble wrote:
> > > > This is useful, but instead of choosing your own method names,
why not
> give
> > it
> > > > an interface consistent with standard iterators (where the
semantics
> match)?
> > > > 
> > > > https://en.cppreference.com/w/cpp/named_req/InputIterator
> > > > 
> > > > I'd leave out the key() and value() methods and let it dealing
with just a
> > > > generic list of SCM values.
> > > > 
> > > > If you implemented enough of the iterator interface, and a class
to wrap
> the
> > > raw
> > > > SCM list into an object addressable with begin() and end(), I
think you
> > would
> > > be
> > > > able to write range-for statements something like this:
> > > > 
> > > > for (SCM assoc : ly_list(my_alist))
> > > >   {
> > > >     SCM key = scm_car(assoc);
> > > >     SCM val = scm_cdr(assoc);
> > > >     ...;
> > > >   }
> > > > 
> > > > If you're not interested in doing this, I might try it myself.
> > > 
> > > By structuring it like this, you enforce the implementation to
store the
> > > key/value as SCM cells, which is exactly what we want to get away
from.
> > 
> > I don't see that there is a plan to get away from the value being an
SCM cell,
> > just the key (at least explicitly).  Am I overlooking something?
> 
> The value itself is not necessarily a cell. You can have #t as a value
(I am
> sure you know that.)

Sure.  Sorry, I assumed you used "cell" colloquially for "SCM" since it
wasn't clear to me that you were talking about the association rather
than their components.

> Making the Key/value combination a cell forces one to store them as
such, or to
> construct a cell on the fly.

Yes, of course.  I thought about key or value being SCM, not about their
association being accessible as a pair or other form of cell.

> There is an experiment where I store keys as uint16.

Sure.

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