From: Robert Klemme <bob.news@...>
Date: 2004-08-12T23:51:10+09:00
Subject: Re: [proto-rcr] Blocks: default arguments and method signatures


"Sam McCall" <tunah.usenet@tunah.net> schrieb im Newsbeitrag
news:1092318554.586276@drone1-svc-skyt.qsi.net.nz...
> Robert Klemme wrote:
> Erk. You're right. I did test it - in irb, having used the name "out" a
> few pages up ;-) Seems like a showstopper.

Unfortunately so...

> >>2) Taking anonymous block parameter, making it part of the signature
> >>Two issues:
> >>   a) If block default values are adopted, then giving the block a
> >>     name might sometimes seem silly, as the name's never used.
> >>     See the above example, "block" is never referenced.
> >>b) No way to specify taking a block as part of method signature.
> >>     Descrptive signatures are good:
> >>     * See syntax in auto-docs/code without reading whole thing
> >>     * See syntax in auto-docs/code when there's no comments
> >>     * Flag errors at start of method, and on every invocation.
> >>
> >>Proposal: allow "&" in place of "&block":
> >>def foo & (or maybe: def foo &!)
> >>As soon as the method is called, raises an error if no block is
> >>given (similar to wrong number of args)
> >>def foo &? (or maybe: def foo &)
> >>No change from current behaviour of def foo, but denotes that
> >>this method can take a block and might use it if given.
> >>(MAYBE:)
> >>def foo &block! or
> >>def foo &!block or
> >>replace current meaning(!) of: def foo &block
> >>This method is required to take a block, not passing a block
> >>raises an error.
> >>def foo &block or
> >>def foo &block? or
> >>def foo &?block, etc
> >>Current meaning of &block.
> >
> >
> > I don't like this one because it's not much of an improvement.  As far
as
> > I can see the only advantage is the automated block check on
invocation.
> Improvements as I see them (excluding default-block-args stuff):
> People reading the documentation/code can see the syntax without reading
> the whole description/method body. This is important to me, maybe not to
> others.

Good point.  I like things that improve doc - especially if it's done
automatically. :-)

> Might be partially soluble by getting rdoc to look for yields.
> Detect errors sooner. My biggest problem with Ruby is errors that aren't
> flagged till runtime. In scripts where there's 5 minutes of startup
> time, this makes debugging SLOW. Fix a bug, wait 5 minutes, fix another
> bug, wait 5 minutes...

You might want to rethink your test scenario if that's possible.

> Detect improbable errors. A method processes some data and takes a block
> which handles erroneous data in some customised way. Not passing a block
> doesn't cause an error if all you data is valid.

Same for methods that not not always yield (in case of an empty collection
for example).  I often do a raise as first line if there is no block.

> >>My preferred syntax in a throw-everything-away-for-Ruby2 scenario:
> >>Named block Anonymous block
> >>Disallowed def foo def foo
> >>Optional def foo &block? def foo &?
> >>Defaulted def foo &block={} def foo &={}
> >>Compulsory def foo &block def foo &
> >>
> >>My preferred syntax in a backwards-compatible scenario:
> >>Named block Anonymous block
> >>Disallowed - -
> >>Optional def foo &block def foo &?
> >>Defaulted def foo &block={} def foo &={}
> >>Compulsory def foo &block! def foo &!
> >
> > Sorry, I don't understand these.  Can you elaborate, please?
> Er. My mailer showed tabs as 8 spaces, and then expanded them to 4, or
> something :-\

Ah, I wondered already why you didn't indent your code.  Then that was
probably the mailer...

> It was *meant* to be a table showing how you would define
> a no-args function called foo that took no block/optional block/optional
> block with default/compulsory block, which would be named/anonymous.
> My (updated) preferred syntax overall (ignoring compatibility):
(1) > Disallowed block: def foo
(2) > Optional anonymous block: def foo &=nil
(3) > Optional named block: def foo &block=nil
(4) > Compulsory anonymous block: def foo &
(5) > Compulsory named block: def foo &block

IMHO (1) and (5) would break too much code.  (2) and (4) necessitate a
parser change.  Matz seems to be reluctant to do these because the parser
seems to be quite convoluted already, which in turn is caused by yacc
AFAIR...

> [Very simple default args (the default must be a proc object,
> block_given? is just "not block.nil?") could be unintrusively done, and
> would probably only be useful for the =nil syntax, and for completeness.
> I think it's worth it ;-)]

I'm not convinced.

> My (updated) preferred syntax overall (backwards compatible):
> Disallowed block: <not possible>

.... as it is today.  Do you really suggest to change it in Ruby 1.x and
change it back in Ruby 2?

> Optional anonymous block: def foo OR: def foo &
> Optional named block: def foo &block
> Compulsory anonymous block: def foo &!
> Compulsory named block: def foo &block!
>
> Thanks for the input, I knew I would have missed something :-)

You're welome.  We all do once in a while.

Kind regards

    robert