|
I think we need to change the name of Buffer's copy method. "Copy" has a special meaning in the language -- it should return a copy of the receiving object (or, for objects like routines that cannot be copied, the receiver itself). Buffer:copy breaks that protocol, because it does work on the server and then returns the receiver. That's inconsistent with basically every other use of "copy" in the language. The specific problem I'm having with this is that we're instructed to use server objects as Pbind child stream values in help files and book examples, but if you use a filter pattern like Pstutter or Pclutch wrapping a pattern that returns buffer objects, the return values that are repeated get copied (which is necessary for events that are returned) and this throws an error because Buffer:copy doesn't get the expected argument values. Although trivial, I think the following should be legal. Currently it isn't. b = Buffer.alloc(s, 512, 1); p = Pstutter(15, b).asStream; p.next; I would suggest this approach for the moment. If the target buffer for the copy is supplied, the copy operation on the server takes place and the user gets a deprecation warning. But if the buf argument is empty, assume that an object copy is meant. + Buffer { copy { arg buf, dstStartAt = 0, srcStartAt = 0, numSamples = -1; if(buf.notNil) { this.deprecated(thisMethod, this.class.findRespondingMethodFor(\copyData)); this.copyData(buf, dstStartAt, srcStartAt, numSamples); } { ^super.copy } } copyData { arg buf, dstStartAt = 0, srcStartAt = 0, numSamples = -1; server.listSendMsg( this.copyMsg(buf, dstStartAt, srcStartAt, numSamples) ) } } Any objection? hjh : 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 |