I get a syntax error on the x=1 part. Am I just using the wrong
syntax? Or is it really not possible to create methods with default
parameter values dynamically?
I get a syntax error on the x=1 part. Am I just using the wrong
syntax? Or is it really not possible to create methods with default
parameter values dynamically?
"Matt Mower" <matt.mower@gmail.com > schrieb im Newsbeitrag
news:d563731905013109382bbeef75@mail.gmail.com...
> Hi.
>
> I want to dynamically create (i'm trying to use define_method) a
> method using which has default values for it's parameters. However
> when I try to do:
>
> define_method "name" lambda { |x=1,y=2,z=3| f(x,y,z) }
>
> I get a syntax error on the x=1 part. Am I just using the wrong
> syntax? Or is it really not possible to create methods with default
> parameter values dynamically?
Ah, thank you -- I had thought of using || to get the defaults but not
to use |*a| to allow parameters to be passed, or not, which is the
vital bit.
Since this workaround is a touch unaesthetic I wonder whether there
was a particular reason for not allowing default values to be
specified for block parameters? Do you happen to know?
Thanks again.
M
···
On Tue, 1 Feb 2005 03:30:46 +0900, Robert Klemme <bob.news@gmx.net> wrote:
"Matt Mower" <matt.mower@gmail.com> schrieb im Newsbeitrag
news:d563731905013110444211811e@mail.gmail.com...
Hi Robert,
>
> "Matt Mower" <matt.mower@gmail.com > schrieb im Newsbeitrag
> news:d563731905013109382bbeef75@mail.gmail.com...
> > Hi.
> >
> > I want to dynamically create (i'm trying to use define_method) a
> > method using which has default values for it's parameters. However
> > when I try to do:
> >
> > define_method "name" lambda { |x=1,y=2,z=3| f(x,y,z) }
> >
> > I get a syntax error on the x=1 part. Am I just using the wrong
> > syntax? Or is it really not possible to create methods with default
> > parameter values dynamically?
>
> I guess you will have to do
>
> define_method( "name" ) { |*a| f(a[0]||1, a[1]||2, a[2]||3) }
>
> Or something similar.
>
Ah, thank you -- I had thought of using || to get the defaults but not
to use |*a| to allow parameters to be passed, or not, which is the
vital bit.
Since this workaround is a touch unaesthetic I wonder whether there
was a particular reason for not allowing default values to be
specified for block parameters? Do you happen to know?
Dunno, but here's my guess: since blocks are usually called at a single
place in code (as opposed to a method) default parameters do not make much
sense generally.
Kind regards
robert
···
On Tue, 1 Feb 2005 03:30:46 +0900, Robert Klemme <bob.news@gmx.net> wrote:
"Matt Mower" <matt.mower@gmail.com> schrieb im Newsbeitrag
news:d563731905013110444211811e@mail.gmail.com...
> Hi Robert,
>
> >
> > "Matt Mower" <matt.mower@gmail.com > schrieb im Newsbeitrag
> > news:d563731905013109382bbeef75@mail.gmail.com...
> > > Hi.
> > >
> > > I want to dynamically create (i'm trying to use define_method) a
> > > method using which has default values for it's parameters. However
> > > when I try to do:
> > >
> > > define_method "name" lambda { |x=1,y=2,z=3| f(x,y,z) }
> > >
> > > I get a syntax error on the x=1 part. Am I just using the wrong
> > > syntax? Or is it really not possible to create methods with default
> > > parameter values dynamically?
> >
> > I guess you will have to do
> >
> > define_method( "name" ) { |*a| f(a[0]||1, a[1]||2, a[2]||3) }
> >
> > Or something similar.
> >
>
> Ah, thank you -- I had thought of using || to get the defaults but not
> to use |*a| to allow parameters to be passed, or not, which is the
> vital bit.
>
> Since this workaround is a touch unaesthetic I wonder whether there
> was a particular reason for not allowing default values to be
> specified for block parameters? Do you happen to know?
Dunno, but here's my guess: since blocks are usually called at a single
place in code (as opposed to a method) default parameters do not make much
sense generally.
I think that's a good assessment... I think historically, they may
have been considered superfluous. But it could change in the future;
with the addition of &block syntax in a block's parameter list
(available now, in 1.9, and later, in 2.0), it might be that block
parameter lists are going to be made more consistent with method
parameter lists.
Maybe
cheers,
Mark
···
On Tue, 1 Feb 2005 17:10:50 +0900, Robert Klemme <bob.news@gmx.net> wrote:
> On Tue, 1 Feb 2005 03:30:46 +0900, Robert Klemme <bob.news@gmx.net> > wrote:
Robert, Mark, thanks for your views. That was really helpful.
M
···
On Tue, 1 Feb 2005 18:27:28 +0900, Mark Hubbart <discordantus@gmail.com> wrote:
On Tue, 1 Feb 2005 17:10:50 +0900, Robert Klemme <bob.news@gmx.net > wrote:
> > Since this workaround is a touch unaesthetic I wonder whether there
> > was a particular reason for not allowing default values to be
> > specified for block parameters? Do you happen to know?
>
> Dunno, but here's my guess: since blocks are usually called at a single
> place in code (as opposed to a method) default parameters do not make much
> sense generally.
I think that's a good assessment... I think historically, they may
have been considered superfluous. But it could change in the future;
with the addition of &block syntax in a block's parameter list
(available now, in 1.9, and later, in 2.0), it might be that block
parameter lists are going to be made more consistent with method
parameter lists.
"Matt Mower" <matt.mower@gmail.com> schrieb im Newsbeitrag
news:d563731905020103585443f29a@mail.gmail.com...
> > > Since this workaround is a touch unaesthetic I wonder whether
there
> > > was a particular reason for not allowing default values to be
> > > specified for block parameters? Do you happen to know?
> >
> > Dunno, but here's my guess: since blocks are usually called at a
single
> > place in code (as opposed to a method) default parameters do not
make much
> > sense generally.
>
> I think that's a good assessment... I think historically, they may
> have been considered superfluous. But it could change in the future;
> with the addition of &block syntax in a block's parameter list
> (available now, in 1.9, and later, in 2.0), it might be that block
> parameter lists are going to be made more consistent with method
> parameter lists.
Even more so if you view blocks / lambdas as nameless functions, which you
can with some justification.
Robert, Mark, thanks for your views. That was really helpful.
You're welcome!
Kind regards
robert
···
On Tue, 1 Feb 2005 18:27:28 +0900, Mark Hubbart <discordantus@gmail.com> wrote:
> On Tue, 1 Feb 2005 17:10:50 +0900, Robert Klemme <bob.news@gmx.net > wrote: