From: "Ara.T.Howard" <Ara.T.Howard@...>
Date: 2005-10-15T00:21:55+09:00
Subject: Re: Default argument values for blocks

On Fri, 14 Oct 2005, Trans wrote:

> I don't think we should be relegated to these kinds of cleverness.

it's not unlike the cleverness of

   method k => v

automagiacally working though is it.  i appreciate the sentiment however.


> It is desireable to have lamda and def have the same basic semantics.

i totally agree - but that would mean

   - def acts as closure.  nothing can now be garbage collected. or lambda does
     not act as closure, lambda is useless without explicit var 'closing'
     abilities or local variable/closure definition similar to the way thread
     works.

   - def returns an object

   - lambda methods can be defined to accept a block, or def ceases to.
     neither seesm plausible

   etc. etc.

in short it seems that merging lambda with def implies a totaly revamping of
ruby into more functional language and that implies a mountain of work, and
for what?  only a little its seems.  the in-between state where ruby lies now
is actually the most practical of places to be.

> OTOH, It would seem in a manner that you are suggesting perhaps we go the
> other way and get rid of default parameters altogeter and use more explict
> means, eg. psuedo-code:
>
>  def foo(?a)
>    a = 1 if a.nack?
>  end
>
> Don;t dismiss the idea so readily either. It does have merit, since default
> parameters are not at all fullproof. No doubt you, like myself often HAVE to
> do something like the above in many cases to prevent certain "bad" arguments
> getting thru.

i'm open to something akin to that.  that's why i wrote parseargs
(http://www.codeforpeople.com/lib/ruby/parseargs/).  note that it works just
fine with either methods OR lambda:

   harp:~ > cat a.rb
   require 'parseargs'
   include ParseArgs

   def method(*a)
     pa = parseargs(a) {
       required_argument :a
       optional_argument :b => 2
     }
     a, b = pa.a, pa.b
     p [a, b]
   end

   method 4
   method 4,2

   method = lambda do |*a|
     pa = parseargs(a) {
       required_argument :a
       optional_argument :b => 2
     }
     a, b = pa.a, pa.b
     p [a, b]
   end

   method[ 4 ]
   method[ 4,2 ]


   harp:~ > ruby a.rb
   [4, 2]
   [4, 2]
   [4, 2]
   [4, 2]


> Default parameters can actually encourage poor management of > parameters.

i agree.  i almost never use them.  keywords are much, much, much better.  i
detest the look of

   render 42, true, false
   render 42, false

huh!?  where are my docs?  where is the code?  (clock ticks...)

   render 42, 'visible' => true, 'badly' => false
   render 42, 'visible' => false

ahhhh - much better.  my take is that arguments are __required__.  period.
anything else is a keyword.

the only exceptions are those cases where a paramter is the default 99% of the
time and a keyword is overkill.  for example

   def log msg, io = STDOUT
   end

but even here this it's perhaps even more an argument to say, instead

   log '42', 'io' => STDERR

since the default arg is used so seldom it nearly always causes whomever is
reading the code to need to consult the docs.  it's especially bad when people
code things like

   def log msg, io = STDOUT, indent = 0
   end

and we're forced to write

   log '42', STDOUT, 7

which is redundant and obscure compared to

   log '42', 'indent' => 7
   log '42', 'indent' => 7, 'io' => STDERR


> So maybe this is a good idea.  And then the whole need for ->(){} would just
> go away.

that's the point - it isn't 'needed'.  unification is a great idea - but's
it's so much bigger that this thread it isn't even funny.  until then, imho,
some new methods are in order.

kind regards.

-a
-- 
===============================================================================
| email :: ara [dot] t [dot] howard [at] noaa [dot] gov
| phone :: 303.497.6469
| anything that contradicts experience and logic should be abandoned.
| -- h.h. the 14th dalai lama
===============================================================================