[lnkForumImage]
TotalShareware - Download Free Software

Confronta i prezzi di migliaia di prodotti.
Asp Forum
 Home | Login | Register | Search 


 

Forums >

comp.lang.ruby

Re: def blah do |x| -- alternate method definition syntax

Yukihiro Matsumoto

11/5/2007 5:24:00 AM

Hi,

In message "Re: def blah do |x| -- alternate method definition syntax"
on Mon, 5 Nov 2007 14:07:21 +0900, Joe Holt <joe07734@gmail.com> writes:

|Friend wondered why a method definition couldn't be like this:
|
|def blah do |x|
| ...
|end

This syntax disallows optional arguments. We can't just parse them.
If you really want to define a method with block parameter style, you
can do:

define_method(:blah) do |x|
...
end

Almost same, isn't it?

matz.

7 Answers

joe07734

11/5/2007 11:59:00 AM

0

Thanks matz and all. The define_method() trick hadn't occurred to me
-- almost the same, indeed. Why couldn't block parameter syntax be
extended to accept optional args: do |x, y=0| ? I Realize that this is
only meaningful for the hypothetical def usage, but come to think of
it I see no reason blocks couldn't accept optional args in cases where
they're .called().

And doesn't calling a proc with [] smell like a cute hack (hey, we've
got this bracket method...) to anyone else?

On Nov 5, 2007, at 12:24 AM, Yukihiro Matsumoto wrote:

> Hi,
>
> In message "Re: def blah do |x| -- alternate method definition syntax"
> on Mon, 5 Nov 2007 14:07:21 +0900, Joe Holt <joe07734@gmail.com>
> writes:
>
> |Friend wondered why a method definition couldn't be like this:
> |
> |def blah do |x|
> | ...
> |end
>
> This syntax disallows optional arguments. We can't just parse them.
> If you really want to define a method with block parameter style, you
> can do:
>
> define_method(:blah) do |x|
> ...
> end
>
> Almost same, isn't it?
>
> matz.
>


Austin Ziegler

11/5/2007 12:41:00 PM

0

On 11/5/07, Joe Holt <joe07734@gmail.com> wrote:
> Thanks matz and all. The define_method() trick hadn't occurred to me
> -- almost the same, indeed. Why couldn't block parameter syntax be
> extended to accept optional args: do |x, y=0| ? I Realize that this is
> only meaningful for the hypothetical def usage, but come to think of
> it I see no reason blocks couldn't accept optional args in cases where
> they're .called().
>
> And doesn't calling a proc with [] smell like a cute hack (hey, we've
> got this bracket method...) to anyone else?

Nope. Not something that seems odd at all after five years of using Ruby. ;)

-austin
--
Austin Ziegler * halostatue@gmail.com * http://www.halo...
* austin@halostatue.ca * http://www.halo...feed/
* austin@zieglers.ca

Phrogz

11/5/2007 1:41:00 PM

0

On Nov 5, 4:59 am, joe07...@gmail.com wrote:
> Thanks matz and all. The define_method() trick hadn't occurred to me
> -- almost the same, indeed. Why couldn't block parameter syntax be
> extended to accept optional args: do |x, y=0| ? I Realize that this is
> only meaningful for the hypothetical def usage, but come to think of
> it I see no reason blocks couldn't accept optional args in cases where
> they're .called().

Because the | operator exists, and there are some edge cases where it
would be hard to determine when the block had ended. Something like:

foo{ |x, y=0| 1+6|7 }

could be either:
foo{ |x, y=0| (1+6|7) }
or
foo{ |x, y=((0|1)+6)| 7 }


IIRC, it's not just that such edge cases exist (where a sane human
could possibly make a choice to disallow certain otherwise-legal
syntax), but that it's very hard or impossible to adjust the syntax
lexer to allow them.

Robert Dober

11/5/2007 1:50:00 PM

0

On 11/5/07, Joe Holt <joe07734@gmail.com> wrote:
> Thanks matz and all. The define_method() trick hadn't occurred to me
> -- almost the same, indeed. Why couldn't block parameter syntax be
> extended to accept optional args: do |x, y=0| ? I Realize that this is
> only meaningful for the hypothetical def usage,
not at all, it is very useful and will therefore be part of Ruby1.9
> but come to think of
> it I see no reason blocks couldn't accept optional args in cases where
> they're .called().
Neither did Matz ;)
>
<snip>

Robert

--
what do I think about Ruby?
http://ruby-smalltalk.blo...

Robert Dober

11/5/2007 1:53:00 PM

0

On 11/5/07, Phrogz <phrogz@mac.com> wrote:
> On Nov 5, 4:59 am, joe07...@gmail.com wrote:
> > Thanks matz and all. The define_method() trick hadn't occurred to me
> > -- almost the same, indeed. Why couldn't block parameter syntax be
> > extended to accept optional args: do |x, y=0| ? I Realize that this is
> > only meaningful for the hypothetical def usage, but come to think of
> > it I see no reason blocks couldn't accept optional args in cases where
> > they're .called().
>
> Because the | operator exists, and there are some edge cases where it
> would be hard to determine when the block had ended. Something like:
>
> foo{ |x, y=0| 1+6|7 }
>
> could be either:
> foo{ |x, y=0| (1+6|7) }
> or
> foo{ |x, y=((0|1)+6)| 7 }
>
>
> IIRC, it's not just that such edge cases exist (where a sane human
> could possibly make a choice to disallow certain otherwise-legal
> syntax), but that it's very hard or impossible to adjust the syntax
> lexer to allow them.
ooops, sorry I was replying to the wrong question

foo { |x,*args,&blk| } will be part of Ruby1.9 and not
foo{ |x,y=42|}
OP can you please post questions that correspond to my answers? Ty very much ;)
R.

--
what do I think about Ruby?
http://ruby-smalltalk.blo...

ThoML

11/5/2007 2:39:00 PM

0

> |def blah do |x|
> | ...
> |end

Would it be possible, hypothetically speaking, to make the parser
digest something like:

def bla do(x, y=1, z=2)
...
end

and (maybe instead of or additionally to the experimental -> syntax)

a = arr.map def(x, y=1) ... end

fn = def(x, y=1) ... end

or

a = arr.map do(x, y=1) ... end

fn = do(x, y=1) ... end

I personally am not very fond of curly braces, vertical bars, and
arrows. Maybe it's because I learned Pascal first.


bermonruf

11/5/2007 3:50:00 PM

0

Note: parts of this message were removed by the gateway to make it a legal Usenet post.

I think its almost perfect the way it is, but i would really enjoy blocks
with optional parameters.


--
Bernardo Rufino