[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Sc-devel] (no subject)
Hi James and Julian,
I think there is some misunderstanding here, which is probably my
The hard and fast rule is that distinct events require distinct Event
objects, always and forever.
The question is whether additional copies are made inside the
evaluation tree. My point is to avoid making
those additional copies.
On Dec 12, 2007, at 8:20 AM, James Harkins wrote:
I would have to vote no, I'm afraid. I routinely write child
patterns in Pbind that look in the partially populated event for
the values of earlier child patterns - Pkey. I mean, I do this all
the time. I can't stress that enough. All the time. This proposal
would break every one of my compositions.
So, Pkey would not be broken at all. In fact, the capability would
be somewhat enhanced as it would be possible
to look back at completed events as well. (It would not be possible
to look back on earlier partial events unless you explicitly
thanks for carrying on with this. Generally, I think it is a good
idea to clarify the input - ouput relation in streams. What about
streams like Pstutter etc?
what happens if, in a Pbind, one of the value streams further up
the chain modify the inevent? then this change would propagate into
Maybe this is a degenerate nodo case ...
Pstutter has to copy, because each event needs a unique Event. (Also
because upstream processing could be depending on the event
being only partially specified.)