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

Re: [Sc-devel] RFC: copy events in the EventStreamPlayer, not the pattern; removing some nil tests from patterns

I think (1) is a good idea... no, an essential idea.

(2) -- I'm afraid I haven't had a chance to review the early termination changes yet :(  but soon. 


On Dec 11, 2007, at 7:55 AM, ronald kuivila wrote:

Hi all,

Two possible changes to Patterns:

1. Currently, EventStreamPlayer uses its protoEvent directly, so patterns that mess with the event must make a copy.  
Feeding a copy of the protoEvent to the EventStream instead of the original would eliminate the need for these copies
(which are found in various Pattern definitions), simplifying code a bit and clarifying what is going on.  

In fact,  the protoEvent is not fully protected from side effects right now:

a = Pbindf(Pfunc { | ev | ev}, \a, 333);
b = a.asStream;
e = ();

b.next(e).postln; e.postln;

2.  Nil is no longer used as to mark an early termination event.  So there are no
(correct) situations where an event pattern returns from yielding its Event "upwards" with a nil.
(Substreams may return a nil, but not the main EventStream.)

So, there are a lot of tests for nil in the code that could go away.
Losing the nil tests implies that  EventStream's receiving a next message
without an event would throw an error.


I am committed to  1 - it simplifies the code in a fundamental way and makes it more secure.  However,
it means that any homemade event stream players have to copy their proto events.  (Are there any homemade
event stream players?)

2. is more of a judgement call, it would get rid of some cruft and make the distinction between substreams and
the main event stream a bit clearer, but it also exposes misuse with error messages.

: H. James Harkins

: jamshark70@xxxxxxxxxxxxxxxxx

: http://www.dewdrop-world.net


"Come said the Muse,

Sing me a song no poet has yet chanted,

Sing me the universal."  -- Whitman