Nick,

A common idiom in type-less languages like Ruby, Smalltalk and others is
that you see class methods that take the parameters specific to that usage.
They then turn around and call an internal method that does the actual
construction and then return the result. Much like the Factory pattern.
This makes sense as each class really is a factory for instances.  It also
makes sense to name creation methods for what they are doing instead of just
'new' with another parameter! In C++ your constructor does both your
instance creation and initialization.  In Ruby specifically, those tasks are
separate. But even with that, one of the ideas of OOP is to have your
problem use the domain language.  That should include creating new objects
you need.  I need a new Point or a new Point with X or a new Point with X
and Y.  So making the creation methods read that way is not such a bad idea.

So we may have these methods (based on your example below)
Point.zero
Point.withX(var1)
Point.withX_withY(var1, var2)

Each of these in turn is implemented something like so:

def Point.zero
    return self.new()

    #Could also do this as well - chaining variant of the idea
    #return Point.withX(0)
end

def Point.withX(var1)
    return self.new(var1)

    #Could also do this as well - chaining variant of the idea
    #return Point.withX_withY(var1, 0)
end

def Point.withX_withY(var1, var2)
    return self.new(var1, var2)
end

def initialize(var1 = 0, var2 = 0)
    @x = var1
    @y = var2
end


This has these positive properties:
1) Method names that mean something in the domain language.
2) Gives class method creation methods that are clearly spelled out. Not
just another variant of new with another parameter
3) Allows the class methods to override the default values if for there case
they want it to be different than what initialize specifics and they are not
given a value for an argument
4) If you use the chaining variant it allows you to work from the most
general usage (no args) to the most specific (all args) and have each
creation method do what it needs to do then pass on the task of creation.
And in Ruby, by the time you get to initialize, lots of error checking on
the args could have already been done, etc. So that initializations need to
do that is minimal.

Hope this idea helps....

-- 
Sam Griffith Jr.
email:      staypufd / mac.com
Web site:   http://homepage.mac.com/staypufd/index.html

On 6/12/2003 12:11 AM, in article bc921m$nmg$1 / titan.btinternet.com, "Nick"
<nick.robinson / f.co.uk> wrote:

> Hi everybody,
> 
> Thanks for the replies.  I appreciate Ruby isnt C++, or C# or Delphi, or ...
> but typically you can have more than one constructor in those languages -
> because typically people have requested the functionality from the language
> because they help.  I think I will reluctantly go with the setting default
> values for the params.  Its not nice in my view, but it will do.
> 
> Thanks to everyone who replied...much appreciated.
> 
> Nick.
> "Jason Creighton" <androflux / remove.to.reply.softhome.net> wrote in message
> news:20030611174214.678930cc.androflux / remove.to.reply.softhome.net...
>> On Wed, 11 Jun 2003 19:36:18 +0000 (UTC)
>> "Nick" <nick.robinson / f.co.uk> wrote:
>> 
>>> Hi,
>>> 
>>> I need to create a class either with a param in the construction or
> nothing:
>>> 
>>> something = Object.new
>>> 
>>> or
>>> 
>>> something = Object.new(val1, val2)
>> 
>> Do it like this:
>> 
>> class Something
>>   def initialize(xdim=defaultval, ydim=defaultvalue)
>>     # do stuff. When xdim or ydim are not given, they will be set to
>> "defaultvalue"
>>   end
>> end
>> 
>> Or, you could gather the args up in an array:
>> 
>> class Something
>>   def initialize(*args)
>>     # Do stuff. args is an array with all arguments given to the method
>>   end
>> end
>> 
>> Jason Creighton
> 
>