Re: Implements rhythmic-music-iterator (issue 5554048)

[dak]

On 2012/01/18 14:36:57, MikeSol wrote:
> On 2012/01/18 14:27:53, dak wrote:
> > Are iterators allowed to change their input?

> I'm not sure if they're allowed by design, but I know they're allowed
to
> proliferate input that wasn't there before.

I don't know what you mean by "proliferate input" as this verb is
intransitive.  If you mean generating new input: sure.  I am worried by
it changing the input.  If it gets iterated in a different context
again, information will be gone.

> One solution is to just set a property in the event
"ignore-articulations".

Where would be the point?  If I plan to touch up the stream event before
broadcasting it, I can't use the everything-included report_event
anyway.  If I plan to touch up the music event in a manner equivalent to
deleting the articulations, I can just delete the articulations instead.
 In either case, the original music event would behave differently after
having once visited the iterator.

So I guess I'll take your patch and just do a bit of copying of what
report_event does.  It is pretty much equivalent to my messing around
with an additional optional boolean argument to report_event, but less
hidden.

Perhaps it would be cleanest to make report_event a virtual function?
Then rhythmic_iterator could just override it.  Better yet, EventChord
could just override it, and we would not need the rhythmic iterator at
all.

http://codereview.appspot.com/5554048/