feedback soo (28 Mar 2004 11:58 UTC)
Re: feedback Shiro Kawai (28 Mar 2004 13:01 UTC)
Re: feedback soo (08 Apr 2004 16:11 UTC)
Re: feedback Paul Schlie (28 Mar 2004 18:04 UTC)
Re: feedback soo (30 Mar 2004 10:28 UTC)
Re: feedback Paul Schlie (30 Mar 2004 14:32 UTC)
Re: feedback Paul Schlie (30 Mar 2004 14:38 UTC)
Re: feedback Paul Schlie (30 Mar 2004 14:59 UTC)
Re: feedback Paul Schlie (30 Mar 2004 15:24 UTC)
Re: feedback Paul Schlie (30 Mar 2004 19:16 UTC)
Re: feedback soo (31 Mar 2004 13:46 UTC)
Re: feedback Paul Schlie (31 Mar 2004 14:58 UTC)

Re: feedback soo 08 Apr 2004 16:09 UTC

 * From: Shiro Kawai <xxxxxx@lava.net>
 * Date: Sun, 28 Mar 2004 03:01:35 -1000 (HST)
 * Subj: Re: feedback

 | From: soo <xxxxxx@tilde.co.kr>
 | Subject: feedback
 | Date: 28 Mar 2004 20:58:51 +0900

   >> | Having two distinct procedures at least help a programmer
   >> | to express the intention.
   >>
   >> At present, I partially agree with you.
   >> How about adding <show> parameter to number type?
   >> Then you can write it like this:

 | My intention was to show just one example of the potential
 | consequences of overloading two functionalities on the same
 | function name.  The similar problem would arise for any
 | of those conflicting arguments such as an integer as <depth> vs <count>,
 | or 'd as <radix> vs <case>.  Unless you make "fmt for number"
 | upper-compatible to "fmt for object" (since a number is an object),
 | you can't write a function which is agnostic to its argument.

Sorry for late response.
I've revised this draft as pointed out above. check it please.

Thanks.
--
INITERM