On Thu, 30 Nov 2000, Dave Thomas wrote:

> Hugh Sasse Staff Elec Eng <hgs / dmu.ac.uk> writes:
> 
> > On Wed, 29 Nov 2000, Dave Thomas wrote:
> > 
> > > 
> > > gsub! and sub! give information that's fairly expensive to determine
> > 
> > But we could introduce sub? -- takes same args as sub! but doesn't change
> > anything, returns true if sub would change anything, false otherwise...
> > This would be less expensive than making the changes in a copy [it would
> > not make the copy or the changes], since as soon as one change was found
> > the thing could stop.  Similarly for sort?, gsub?, reverse?, rather than
> > checking afterwards....
> 
> OK, and that's effectively what Ruby does now. However, that isn't

Its ! ops make the changes, these would not.

> quite what the intent is. For example
> 
>     "cat".sub!(/../, 'do')   => dot
>     "dog".sub!(/../, 'do')   => dog
> 
> Should the last one be 'nil'? If not, why not?

Oh, I missed this subtlety before.  I'd say the least surprising thing
would be to not return nil, because in this case it means doing an exta
comparison on top of {match ? change : don't change}. The second pattern
could be quite complex, with \1 etc in it, so one would not want this
extra work....  I think.  Or have I missed something else?

> 
> I come back to the point, though. Is it ever used, and if so, does it
> _really_ mean that the string is unchanged, or is it taken to mean
> that the pattern did not match (in which case the language already has 
> constructs we can use).
> 

OK, suggestions for gsub? and sub? withdrawn.  I can see cases
with general objects in arrays where sort? and reverse? could
still be used, but how often and at what code bloat cost I cannot
say.
 
> 
> Dave
> 
> 
	Hugh
	hgs / dmu.ac.uk