Bert Huijben wrote:
>> -----Original Message-----
>> From: Greg Stein [mailto:gstein_at_gmail.com]
>> Sent: Wednesday, January 28, 2009 12:26 AM
>> To: dev_at_subversion.tigris.org
>> Subject: Re: svn commit: r35512 - in trunk/subversion: include
>> libsvn_client svn
>> I disagree with this change.
>> You're adding a bunch of complexity in order to save *three*
>> arguments? That is a very poor tradeoff. Now we have a structure,
>> constructors, people have to create/init that structure to call the
>> function, the function will just unpack its values, etc.
>> Now, if there were *ten* arguments, then... well, probably still "no".
>> Packing arguments into a struct to be unpacked within the function
>> generally does not help anything. It just makes it harder to use.
> This specific example was discussed on this list a few months ago as a
> specific example when to introduce an args structure. The work just wasn't
> completed before.
> See: [RFC] Introducing svn_client_make_diff_args? (Was: ...)
> http://svn.haxx.se/dev/archive-2008-09/0674.shtml (Google reference, but url
> is down right now)
> We are on svn_client_status4 right now, with only 6 point releases,
> svn_client_log5, svn_client_diff5.. Let's go to svn_client_status99 then and
> let all 98 others be deprecated but be part of our code before 2.0.
> Providing functions with dozens of Boolean arguments doesn't give us a clean
> api. Using an args object with a good set of defaults makes the choices
> explicit in code and commit logs without referring to the help (or
> intellisense of your favorite editor) to see what the seventh Boolean is
> See also the forwarding of the args inside the status call to the next call
> for the externals. It reduced extra arguments there again.
Bert, I gotta say I that I, too, disapprove of this change, and absolutely
do not want to go down this path. The closest to this that I would agree to
go would be to combine all the booleans into a field of bitflags. But
generic structures of function args are, as Greg as noted, just a lot of
pain for precious little gain.
As for svn_client_status99() ... that's a tad over-dramatic, don't you think?
C. Michael Pilato <cmpilato_at_collab.net>
CollabNet <> www.collab.net <> Distributed Development On Demand
Received on 2009-01-28 16:16:50 CET