Response at bottom > -----Original Message----- > From: David Alan Black [mailto:dblack / candle.superlink.net] > Sent: Wednesday, August 07, 2002 6:57 PM > To: ruby-talk ML > Subject: RE: Named paramters again > > Hi -- > > On Thu, 8 Aug 2002, Rich Kilmer wrote: > > > Named parameters can also be used to allow for methods where default > > values are supplied for specific parameters: > > > > def foo(x, y=2, z=3) > > ... > > end > > > > If you want to call this and set 'z' but leave 'y' is default value, > > named parameters are your friend. > > > > foo(2, z: 4) > > > > Where this is used a lot in python are constructors in GUI widgets were > > lots > > of default values can be set and you only need to provide those you wish > > to > > 'override'...and yes...order independence becomes relevant here too > > because you will have a hard time maintaining the order in your head for > > 20 or 30 parameters. Granted, you could just implement this as > > subsequent calls to attribute getter/setters, but it's nice to be able > > to do it in widget construction. > > I'm completely GUI-programming ignorance, but I'll accept on faith > that the interface authors have good reason to do it this way (rather > than wrapping the arguments up in an object). But I'm still not sure > this should be taken as a model for language-level change. Isn't it > sort of good that the language doesn't make 20-parameter methods > convenient? :-) > > Well, I agree that it's a code smell to accept 20 params in a constructor, but named parameters are still useful in the above mentioned (3 param) method call. Where the first param is required, the other two have a default value, and you want to change the value of the third param. In Ruby you could (as easily) do this instead of the 20 param thing. class Widget attr_accessor :x, :y, :z def initialize(&block) @x=0 @y=0 @align=:center # ... lots of other params instance_eval &block if block_given? end end Widget.new {@align=:left} Which is how I solved it for my GUI abstraction layer.