Re: [sc-dev] string.replace

[Dan Stowell <danstowell+sc3@xxxxxxxxx>]

FWIW, I guess my vote would be for the primitive to be modified simply
so that in addition to current behaviour, it can also replace a Char
(or any subclass!) instance within a String...

Best
Dan

2015-12-03 11:16 GMT+00:00 Scott Wilson <i@xxxxxxxxxxxxxx>:
> :-)
>
> Agreed!
>
> I agree it’s better to do it in the primitive. (Also better than a new
> asSomething approach, we’ve got so many of those now…)
>
> I’m happy to do that if we can agree on what it should accept. Once that’s
> done we should make sure to clearly document it. The very vague
> documentation of things often makes it very hard to tell what things are
> accidents and what are intentional.
>
> S.
>
> On 3 Dec 2015, at 08:25, Chris Sattinger <crucialfelix@xxxxxxxxx> wrote:
>
>
> sorry, that would be:
>
> n = nil;
> "magniloquent".replace(n, "OUCH");
>
> "magOUCHoquent"
>
>
>
> On Wed, Dec 2, 2015 at 10:21 PM Chris Sattinger <crucialfelix@xxxxxxxxx>
> wrote:
>>
>>
>> So we could just add this:
>>
>> replace { arg find, replace;
>>         find = find.asString;
>>         ^super.replace(find, replace).join
>> }
>>
>> that would be messy:
>>
>> n = nil;
>> "blarg".replace("la", n);
>>
>> "bnilrg"
>>
>>
>>
>> On Wed, Dec 2, 2015 at 6:53 PM Scott Wilson <i@xxxxxxxxxxxxxx> wrote:
>>>
>>> Context:
>>>
>>> This happened as I found some silent failures, which led to a review of
>>> all primitives to identify ones which did not check for bad types and
>>> swallowed errors. There were a number where this was incorrectly done and
>>> stuff would just quietly not work.
>>>
>>> The String ones perhaps need more nuanced handling, although FWIW I did
>>> check with the original author of the relevant code to see if the previous
>>> implementation of those was intentional or just an oversight. It wasn’t
>>> intentional.
>>>
>>>
>>> Yes, this is a consequence of that change. We should keep considering the
>>> way it behaves, however.
>>>
>>>
>>> I can adjust these to accept other types. What would be helpful would be
>>> if we could first come up with a specification for what such methods should
>>> accept. Certainly Chars seem reasonable in this case.
>>>
>>> S.
>
>



-- 
http://www.mcld.co.uk

_______________________________________________
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/