Re: [sc-dev] string.replace

[Julian Rohrhuber <julian.rohrhuber@xxxxxxxxxxxxxxxxxx>]

> On 02.12.2015, at 03:04, James Harkins <jamshark70@xxxxxx> wrote:
> 
> On December 2, 2015 3:49:25 AM Chris Sattinger <crucialfelix@xxxxxxxxx> wrote:
> 
>> Is this known and intentional ? I think its a recent change.
>> update and compiled today
> 
> Previously, in the case of a wrong type passed to String:compare, it would return nil. This was not ideal because, for instance, "abc" < 5 would print an error that nil does not understand '<' -- confusing for the user because of course there is no "nil" in that expression.
> 
> Now it throws a wrong type error. This is more technically sound IMO, but it did break a few things. We probably haven't seen all the fallout yet.
> 
> This was extensively discussed... ad nauseam... on github.


Yes, this is a consequence of that change. We should keep considering the way it behaves, however.

This works:

[1, 2, 3].replace(2, pi)

But this not:

“123”.replace($1)

This is not such a good idea to break the uniformity.

in ArrayedCollection, this is implemented as:

replace { arg find, replace;
		var index, out = [], array = this;
		find = find.asArray;

which in turn uses SequenceableCollection:find, which compares arrays.

So we could just add this:


replace { arg find, replace;
	find = find.asString;
	^super.replace(find, replace).join
}

this might be overly permissive though. On the other hand, “join” also implicitly calls asString on its joiner (<< on a string stream).





_______________________________________________
sc-dev mailing list

info (subscription, etc.): http://www.birmingham.ac.uk/facilities/ea-studios/research/supercollider/mailinglist.aspx
archive: https://listarc.bham.ac.uk/marchives/sc-dev/
search: https://listarc.bham.ac.uk/lists/sc-dev/search/