[#41431] [ruby-trunk - Bug #5694][Open] Proc#arity doesn't take optional arguments into account. — Marc-Andre Lafortune <ruby-core@...>

27 messages 2011/12/01
[#41442] [ruby-trunk - Bug #5694] Proc#arity doesn't take optional arguments into account. — Thomas Sawyer <transfire@...> 2011/12/01

[#41443] Re: [ruby-trunk - Bug #5694] Proc#arity doesn't take optional arguments into account. — Yehuda Katz <wycats@...> 2011/12/01

Maybe we can add a new arity_range method that does this?

[#41496] [ruby-trunk - Bug #5714][Open] Unexpected error of STDIN#read with non-ascii input on Windows XP — Heesob Park <phasis@...>

22 messages 2011/12/06

[#41511] [ruby-trunk - Bug #5719][Open] Hash::[] can't handle 100000+ args — Nick Quaranto <nick@...>

13 messages 2011/12/07

[#41557] [ruby-trunk - Bug #5730][Open] Optinal block parameters assigns wrong — Yukihiro Matsumoto <matz@...>

14 messages 2011/12/08

[#41586] [ruby-trunk - Feature #5741][Open] Secure Erasure of Passwords — Martin Bosslet <Martin.Bosslet@...>

17 messages 2011/12/10

[#41672] [ruby-trunk - Feature #5767][Open] Cache expanded_load_path to reduce startup time — Yura Sokolov <funny.falcon@...>

13 messages 2011/12/15

[#41681] Documentation of the language itself (syntax, meanings, etc) — Rodrigo Rosenfeld Rosas <rr.rosas@...>

Since Ruby is built on top of simple concepts, most of the documentation

23 messages 2011/12/15
[#41683] Re: Documentation of the language itself (syntax, meanings, etc) — Gary Wright <gwtmp01@...> 2011/12/15

[#41686] Re: Documentation of the language itself (syntax, meanings, etc) — Rodrigo Rosenfeld Rosas <rr.rosas@...> 2011/12/16

Em 15-12-2011 19:23, Gary Wright escreveu:

[#41717] Feature : optional argument in File.join — Michel Demazure <michel@...>

In Windows, when using File.join, one often ends with a path containing

13 messages 2011/12/19
[#41719] Re: Feature : optional argument in File.join — Luis Lavena <luislavena@...> 2011/12/19

On Mon, Dec 19, 2011 at 6:09 AM, Michel Demazure <michel@demazure.com> wrot=

[#41720] Re: Feature : optional argument in File.join — Michel Demazure <michel@...> 2011/12/19

Luis Lavena wrote in post #1037331:

[#41728] [ruby-trunk - Feature #5781][Open] Query attributes (attribute methods ending in `?` mark) — Thomas Sawyer <transfire@...>

15 messages 2011/12/19

[#41799] Best way to separate implementation specific code? — Luis Lavena <luislavena@...>

Hello,

15 messages 2011/12/24
[#41800] Re: Best way to separate implementation specific code? — KOSAKI Motohiro <kosaki.motohiro@...> 2011/12/24

2011/12/24 Luis Lavena <luislavena@gmail.com>:

[#41811] Re: Best way to separate implementation specific code? — "U.Nakamura" <usa@...> 2011/12/26

Hello,

[#41817] Re: Best way to separate implementation specific code? — Luis Lavena <luislavena@...> 2011/12/26

On Sun, Dec 25, 2011 at 10:51 PM, U.Nakamura <usa@garbagecollect.jp> wrote:

[#41812] [ruby-trunk - Feature #5809][Open] Benchmark#bm: remove the label_width parameter — Benoit Daloze <redmine@...>

11 messages 2011/12/26

[ruby-core:41699] Re: Documentation of the language itself (syntax, meanings, etc)

From: Rodrigo Rosenfeld Rosas <rr.rosas@...>
Date: 2011-12-16 14:12:32 UTC
List: ruby-core #41699
Em 16-12-2011 02:28, Gary Wright escreveu:
> On Dec 15, 2011, at 10:39 PM, Rodrigo Rosenfeld Rosas wrote:
>> If returning from another method was possible, the framework could make the render method return automatically after being called, for example. That way, you would be able to simply write:
>>
>> def action
>>     render text: "failure while creating post" unless Post.create(params)
>>     expire_cache_from_post_list
>>     render view: 'list'
>> end
>>
>> And this is much more readable to me from the perspective of someone used to web programming. It would be implicit to the developer that either "return" or "render" would stop the method execution. In frameworks that don't support rendering by convention (you must call render explicitly) it wouldn't even make sense to see a return in such action methods.
> Even if it were possible, you are suggesting that there should be a way for a regular method call (render in your example) to never return but instead for control to be passed back to the caller of action.  I think that sort of "magic" would be very difficult to work with.  There is nothing visible in the code you gave to indicate that the flow of control is radically different than what is normally expected.  This seems like poor cost/benefit trade off to me.
>
> Of course there is already a standard mechanism for unwinding the stack, exceptions.
>
> By using exceptions you can sort of create the control flow you are looking for.  At least this way the rescue clause is there to give the reader a hint that something unusual is happening.  In this example, render_then_raise would raise ReturnNowException (yeah, bad name) to bypass the remainder of action.
>
> def action
>    render_then_raise text: "failure while creating post" unless Post.create(params)
>    expire_cache_from_post_list
>    render view: 'list'
> rescue ReturnNowException
>    return
> end

The problem with this is that you would need to repeat this pattern for 
every action in you controllers.

In This Thread