Why?:
1- Huffman. "req" is a valuable 3-letter token for a low-frequency
method.
2- "req" is insufficiently descriptive. "arity" is vastly superior
in this regard.
=Austin
> Request: Change .req method of Routine to .arity
I rather like this idea.
Damian
It only has "value" if there's a better use for it. :)
--
IDIOCY:
Never Underestimate The Power Of Stupid People In Large Groups
I'm not attached to ".req". But ".arity" will be opaque to many
non-mathematicians. Plus, it's throwing out "minimum" part of the
notion "minimum number of arguments". So if you want something longer
I would be happy with ".minargs" or ".reqargs" or some such.
But a ".maxargs" seems rather less useful, unless you know the types
of all the optional parameters, in which case you probably know how
many optional parameters have been declared in any event.
On the other hand, I could see an argument that said anyone who
doesn't know what .arity means shouldn't be writing routines that
depend on it...
Larry
> On the other hand, I could see an argument that said anyone who
> doesn't know what .arity means shouldn't be writing routines that
> depend on it...
That was more or less my line of thought.
Damian
Now, I think I'll dare claim my English is not exactly bad for a 21
year-old non-native speaker. Being a physics and CS student, I do also
have mathematical background, but it still took me a few seconds to
figure out "arity" *in this context*. Maybe that's because I can't think
of an exact German equivalent either; maybe it's because I don't think a
function's arity is quite the same as it's *minimum* number of
parameters? I mean, it makes sense in a functional language... but you
don't have functions with a variable number of arguments there.
To cut this short: I think req or reqargs or somesuch would be better.
Why choose the method names that sound more like computer science for
the very sake of that?
Steffen
--
sub'_{q} tsuJ}}_();sub's{seek+DATA,0,0}sub'p{print&_}sub'r{reverse$_[0]}
@_=(('')x2,split" ",<DATA>);s!!&s,$_=<DATA>;s/}.*?}/$_[$s+1]/
if$s;s/(}.*?})/r$1/e;eval$_;p,$s++!efor@_[0..3];
__DATA__
} rehtona} } lreP} },rekcah}
(Your English sounds pretty darned good to me. :)
> To cut this short: I think req or reqargs or somesuch would be
> better. Why choose the method names that sound more like computer
> science for the very sake of that?
FWIW, I'm a CS professional with an appalling lack of mathematical
background (though I scored above the math average for Engineers on my
GRE, and didn't miss any of the logic questions). I'd never *heard* of
"arity", but tend to use esoteric language attributes rather often
(which is not a boast -- it's a rather bad habit, but there it is).
Anyway, I like writing functions and methods that DWIM, but sometimes
WIM takes some doing. I'd rather have a name that means something to
me, too.... though to be honest, "arity" would mean something to me, if
someone would just explain it, lol....
Paul
__________________________________________________
Do you Yahoo!?
Yahoo! Platinum - Watch CBS' NCAA March Madness, live on your desktop!
http://platinum.yahoo.com
http://www.dictionary.com/search?q=arity
1 entry found for arity.
arity
<programming> The number of arguments a function or
operator takes. In some languages functions may have
variable arity which sometimes means their last or only
argument is actually a list of arguments.
(1997-07-21)
Source: The Free On-line Dictionary of Computing, © 1993-2001 Denis
Howe
=Austin
Sure, but one can imagine having functions with a given arity that
can nonetheless be modified adverbially. In this view, required
parameters contribute to "arity", but optional parameters are only
used for, er, options.
Larry
[I wrote:]
> : maybe it's because I don't think a
> : function's arity is quite the same as it's *minimum* number of
> : parameters? I mean, it makes sense in a functional language... but you
> : don't have functions with a variable number of arguments there.
>
> Sure, but one can imagine having functions with a given arity that
> can nonetheless be modified adverbially. In this view, required
> parameters contribute to "arity", but optional parameters are only
> used for, er, options.
I can see your point, but I still think this is kind of warping the way
people think of an n-ary function (if they do think of functions to have
an arity in the first place).
Steffen
--
@n=([283488072,6076],[2105905181,8583184],[1823729722,9282996],[281232,
1312416],[1823790605,791604],[2104676663,884944]);$b=6;@c=' -/\_|'=~/./g
;for(@n){for$n(@$_){map{$h=int$n/$b**$_;$n-=$b**$_*$h;$c[@c]=$h}reverse
0..11;push@p,map{$c[$_]}@c[reverse$b..$#c];$#c=$b-1}$p[@p]="\n"}print@p;