Boost logo

Boost :

From: Reid Sweatman (reids_at_[hidden])
Date: 1999-06-18 17:35:15


I know I'm a newbie here, but thought I'd toss my .02 Zorkmids into the hat.
I think some of the confusion over the argument naming schemes comes from
the fact that they're not derived from CS argument-naming schemes, but from
the operator notation of mathematics. Unless someone with a fierce Ph.D. in
math cares to correct me, I believe that operator notation doesn't support
null domains, which is what having a "non-ary" C++ function would amount to.
Hence, there's no name for it. Operator notation is intended to describe
ideas related to functions (in the mathematical sense), transforms,
mappings, etc. Note that I use all those words in their mathematical
contexts, in which in every case there is a domain which the operator maps
into a range. Here the domain can be of any dimensionality, except null
(even having only an identity element, or null kernel under the operations
implies a dimensionality of at least one).

Would it be out of line to suggest a naming scheme that *isn't* based on
operator notation? Maybe something that explicitly uses the word
"argument," or "parameter," or some abbreviation of something like that?
That would give you a simple, consistent, easy-for-anyone-to-understand
notation, with names like one_arg_function, two_arg_function, and so on. I
know they don't have the nifty complex mathematical sound of the other
suggestions, but being a mathematician myself, I'd call that a plus (which,
of course, is a two_arg_function <g>). Lucky for us that C++ doesn't
support more than one return value, or we'd have to factor the
dimensionality of the return values into the name as well <g>.

Anyway, as I said, my .02 Zorkmids (which, according to Michael Dornbush,
are now collectors' items worth around $65 apiece <g>).

> -----Original Message-----
> From: Nathan Myers [mailto:ncm_at_[hidden]]
> Sent: Friday, June 18, 1999 2:44 AM
> To: boost_at_[hidden]
> Subject: [boost] Re: result of compose discussion
>
>
>
> > For the question of "nonary_function" "nullary_function",
> > "niladic_function", "voidary_function", ...
> > it seems we get more and more suggestions.
> > So, for the moment I stay with "nonary_function".
>
> "Nonary" is abominable, but should remain as a goad until somebody
> comes up with a good reason to favor one among the others. What's
> wrong with "nonary"? First, it implies nine arguments.
>
> Of the suggestions I have seen, niladic or nullary seem best.
>
> Nathan Myers
> ncm_at_[hidden]
>
>
> --------------------------------------------------------------
> ----------
> eGroups now offers FREE email newsletters!
> Women.com, RollingStone, Travelocity, and more...
> Sign-up Now! http://clickhere.egroups.com/click/315
>
>
> eGroups.com home: http://www.egroups.com/group/boost
> http://www.egroups.com - Simplifying group communications
>
>
>
>

------------------------------------------------------------------------

eGroups.com home: http://www.egroups.com/group/boost
http://www.egroups.com - Simplifying group communications


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk