[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: [patch] Use hash for optional args with long argument list in Ruby bindings

From: Joe Swatosh <joe.swatosh_at_gmail.com>
Date: 2007-11-15 06:32:45 CET

Hi kou,

On Nov 14, 2007 3:09 AM, Kouhei Sutou <kou@cozmixng.org> wrote:
> Hi,
>
> In <ae6cb1100711130654k5947f6c6q766f2778c67624d7@mail.gmail.com>
> "Re: [patch] Use hash for optional args with long argument list in Ruby bindings" on Tue, 13 Nov 2007 06:54:11 -0800,
> "Joe Swatosh" <joe.swatosh@gmail.com> wrote:
>
> > > > Although I didn't modify Hash for checking like the example from ActiveSupport
> > > > that you showed. It didn't seem right to modify a standard class from the SVN
> > > > bindings.
> > >
> > > OK. I agree with you.
> > > I want to define them in Svn::Util.
> >
> > Should we create a new file in svn called util.rb for the module?
> > Then just include it in Context?
>
> We have the file.
> I think we don't need to use include. We just use the method
> as module_function like Util.validate_options(options, VALID_OPTION_KEYS).
>
> > Okay, I'm feeling thick this morning the the fragments below aren't making much
> > sense to me. Do you mean "# the current updated_editor2 API" below?
>
> Sorry. Yes. You're right.
>
> > Are
> > you suggesting keeping the many optional argument version?
>
> No. I want to remove the current update_editor2.
>
> > If so, why don't we
> > leave Svn::Client::Context#update_editor2 alone and add a
> > Svn::Client::Context#update_editor3 that uses the Hash arguments?
>
> I want to make a rule that XXX2 API is a hash argument
> version of XXX2 API. So I want to provide update_editor2 as
> hash argument version API.
>
>

I'm still not certain I understand, but I did understand that you said
"commit."
So I did, with the modification that you suggested of moving the
validate_options
method from Svn::Client::Context to Svn::Util. Now at least you can work on
it to show me exactly what you mean.

--
Joe
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu Nov 15 06:32:57 2007

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.