Hi Scott, That is a good question! I thought I knew the answer, but decided it would take poking around to see what is actually being done. The general answers that came to mind: Currently there are no implementations of 'next' that take more than one argument. 'next' is part of the Stream interface. If Function:next were the same as Function.value then Function.embedInFunction should probably be { | ev | ^this.value(ev).yield } This makes it marginally more difficult to define a pattern whose values are Functions. (You would need to add another set of braces around each function.) Here is some data from munging around in the class library: There are 92 classes that implement 'value', almost all use Object's implementation of next. Here are the exceptions (class that defines value followed by class that defines next): [ Ref, Maybe ] [ MXHIDSlot, MXHIDRelSlot ] [ Editor, EnvEditor ] [ Editor, Editor ] [ MXHIDSlot, MXHIDSlot ] [ Position, Position ] [ Instr, Instr ] [ Thread, Thread ] [ MXHIDSlot, MXHIDLedSlot ] [ Ref, Ref ] [ Routine, Routine ] [ Stream, Stream ] [ Ref, FuncProxy ] Of these, only Position and Instr do anything out of the ordinary. Position is advanced by next while value returns the current position. Instr expects an array of arguments for value (almost certainly an error since it also responds to valueArray). (i haven't had the heart to go look at all the other classes that implement value to see what is going on there.) Below is a list of classes that implement 'next' and what class implements 'value'. The first 9 do not conform in some more or less significant way to the convention that next is equivalent to value. [ Object, LinkedListNode ] // next is a link [ Object, Tempo ] // next streams the tempo [ Object, Meta_Tempo ] // ditto for Tempo.default [ Object, Meta_UniqueID ] // ID allocators [ Object, PowerOfTwoBlock ] [ Object, SerialPort ] [ Position, Position ] // next advances the position, value returns current position [ Instr, Instr ] // value expects an array of args, next doesn't // possible mistake as there is valueArray as well [ Thread, Thread ] // explicitly set to return Thread in response to value [ Object, Event ] // these return a copy in response to 'next' [ Ref, RefCopy ] [ Object, Object ] // these all conform to the next <=> value convenntion [ MXHIDSlot, MXHIDSlot ] [ Routine, Routine ] [ Editor, Editor ] [ Stream, NAryOpStream ] [ Stream, BinaryOpXStream ] [ Stream, EventStreamPlayer ] [ Stream, CollStream ] [ Stream, UnixFILE ] [ Stream, StreamClutch ] [ Stream, OneShotStream ] [ Stream, BinaryOpStream ] [ Stream, UnaryOpStream ] [ Stream, EmbedOnce ] [ Stream, FuncStream ] [ Stream, PauseStream ] [ Stream, Stream ] [ Stream, CleanupStream ] [ Ref, Ref ] Here is how I looked for them: a = Class.allClasses.collect { | c | var m; m = c.findRespondingMethodFor('value'); if (m.notNil) { m.ownerClass } { Object }; }.asSet b = a.collect { | c | var m; m = c.findRespondingMethodFor('next'); if (m.notNil) { m.ownerClass } { Object }; }.asSet On Dec 19, 2007, at 8:06 AM, Scott Wilson wrote:
|