From: Hugh Sasse Staff Elec Eng <hgs@...>
Date: 2000-07-06T13:09:07+01:00
Subject: [ruby-talk:03868] Re: Array.uniq! returning nil

On Thu, 6 Jul 2000, [iso-8859-1] Aleksi Niemel� wrote:

> > def sub!(pattern, substitution, no_change_gives=nil)
> >     #...
> > end
> 
> This might be good idea. However I'd like to have a field in String which
> describes what to return when no_change_gives equals to nil (kind of dynamic
> default value :). Then all the programs work as previously, but when new

	that default '=nil' preserves current behaviour.

> code is written one could say:
> 
>   Array.no_change_default_value = "self"  # or whatever way to return self

        def uniq!(no_change_gives=nil)
        end

	myarray.uniq!(myarray)	# would explicitly return myarray instead
				# of nil
        myarray.uniq!() 	# would return nil, as before
	myarray.uniq!(["grated", "cheese"])	# would return that arbitrary
				# array.  All this using the optional
				# no_chage_gives parameter.

	Why do you need more flexibility than this?  If you change
	the *default* behaviour, this will make debugging harder.  At
	least in each case where you need it, things are spelled out
	locally in the code, using an extra parameter.  You can 
	always wrap this with my_uniq! which flags you are doing 
	something unusual.  Otherwise:

	Array.no_change_default_value = "The Spanish Inquisition"
	my_array.uniq!()  # I didn't expect....

	"Our main weapon is the principle of least surprise!".
> 
> Then code like array.uniq! would always return nil. The problem with this is
> that it just wont work in mixed world where new code calls old code.

	with an optional parameter, old code won't use it, new code may
	use it.  The new code would not run on an old ruby. That is true.
> 
> So I guess if there's going to be any consensus here, we will have it
> changed to some major version (like 1.8).
> 
> 	- Aleksi
> 
> 
	Hugh
	hgs@dmu.ac.uk