[#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:41700] Re: Documentation of the language itself (syntax, meanings, etc)

From: Peter Vandenabeele <peter@...>
Date: 2011-12-16 14:34:42 UTC
List: ruby-core #41700
On Fri, Dec 16, 2011 at 3:12 PM, Rodrigo Rosenfeld Rosas <rr.rosas@gmail.com
> wrote:

> 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.
>

Do I understand correctly that It would make sense if the Web framework
would
provision a default rescue or catch around the call it makes to the action.
If
so, we could try to make this a feature for Rails.

Peter

-- 
Peter Vandenabeele
http://twitter.com/peter_v
http://rails.vandenabeele.com

In This Thread