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

From: Rodrigo Rosenfeld Rosas <rr.rosas@...>
Date: 2011-12-20 12:52:08 UTC
List: ruby-core #41753
Em 19-12-2011 23:35, Eric Hodel escreveu:
> On Dec 19, 2011, at 3:04 PM, Rodrigo Rosenfeld Rosas wrote:
>> Em 19-12-2011 19:38, Eric Hodel escreveu:
>>> On Dec 15, 2011, at 7:39 PM, Rodrigo Rosenfeld Rosas wrote:
>>>> Yeah, I already knew about all this. What I'm asking is why Ruby won't allow me to return from another method, ie, passing procs between different methods that will allow me to return from any method through that proc...
>>>>
>>>> I would like to know the reasoning behind this design decision... Is it just difficult technically to implement such behavior, or is it undesired? For the latter case, I would like to know why it is undesired...
>>> Continuations allow you to arbitrarily unwind the stack, but you probably want to avoid using them because they're tricky to use correctly:
>> Using global variables ($cont) in multi-threaded web servers is impractical, so it wouldn't work for what I'm looking for.
> The global variable was simply an example, you can store continuations in any type of variable, constant, etc.

Yeah, Eric, sorry, I was tired yesterday night when I read your message. 
I could even use thread variables if I wanted to, although for my case 
an instance variable would probably be enough.

But anyway, could you give me a concrete example on how I could 
implement something like render_and_return using continuations in my 
controllers?

>> In the other hand, catch-throw could work, but I would depend on the propose being accepted by the web framework being used, or maintaining some monkey patch myself, which I don't think would worth the extra "return"s saved.
>>
>> But don't get me wrong, I'm not insisting that Ruby should add support for such a feature. Actually, I've never asked for it, I was just wondering what are the reasons why this isn't supported by Ruby, but it was already pointed out to me that it could make code debugging very hard, which I agree> Continuations support what you want and much more, but due to the difficulty of debugging and understanding code using such constructs ruby does not support such a thing as a direct language feature.
>
> You should be fortunate that you can implement the feature you want using continuations or catch/throw.  There are many other languages where implementation of such a feature would be vastly more difficult.

Yes, I am. Can't complain about Ruby itself.

>> I hope web frameworks will provide such feature by using some catch-throw implementation some day.
> You will need to send feature requests.

I've sent it yesterday to Rails, just after sending my message:

https://groups.google.com/group/rubyonrails-core/browse_thread/thread/116ec2e46a04671c

But as I was already expecting I had already some negative responses and 
no positive one yet...

It seems like Sinatra already supported this, but my web framework of 
choice is currently Rails :P

In This Thread