Newsgroups: comp.lang.dylan
Path: cantaloupe.srv.cs.cmu.edu!das-news2.harvard.edu!news2.near.net!howland.reston.ans.net!ix.netcom.com!netcom.com!rlo
From: rlo@netcom.com (Robert Orenstein)
Subject: Re: Two Dylan Questions
Message-ID: <rloD1wGus.8y2@netcom.com>
Organization: NETCOM On-line Communication Services (408 261-4700 guest)
References: <rloD1tKCG.7D6@netcom.com>
Date: Wed, 4 Jan 1995 21:25:40 GMT
Lines: 37

I wrote:

>Does this mean (and my experimentation leads me to belive that it does)
>that there is no way to have two methods with the same name unless
>they have the same number of parameters?  If so, why was this choice made?
>Doesn't this require the programmer to know the names of all methods in
>any library they're using in order to avoid conflicts in method names?
>And doesn't this work against one of the main benefits of object oriented
>programming?  If this is indeed a limitation, are there any workarounds?

... and a bunch of people gave good answers.

Thanks for the replies, everyone.  But I'm still curious as to the REASONS
for the restriction that requires generic functions to have the same number
of required parameters.  The Dylan design note "42-implicit-gf-param-lists"
says that 

  As a general principle, the parameter list of the implicitly 
  defined generic function should impose as few constraints as possible on 
  the methods that may be added. 

but then further states that 

  Either [methods defined under the same generic function] must all 
  require a fixed number of arguments, they must all accept a variable 
  number of arguments, or they must all accept keyword arguments.  
  A set of methods that includes members with more than one of these 
  patterns violates the parameter list congruency requirement, and is an 
  error.

Given the general principle that there should be as few constraints
as possible, why is this particular restriction necessary?  MacMarlais
seems to ignore this restriction entirely, and the restriction does
seem to impose an unnecessary restraint on what is to some (well, to me
anyway), their own "natural" way of programming.

Robert Orenstein
