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
===============================================================================
foo=3D"bar"){puts foo}"? It's still not beautiful but= it's