Ask and ye shall receive. This doesn't, of course, help existing Rails installs, but it's a step in the right direction.
For those of you just joining us: JRuby does not support the block param format described below. I asked Matz to point me toward where in the C code this trick is done, and he cautioned me that this would not be supported in the future. I'm all for not implementing things that are going away.
---------- Forwarded message ----------
From: Ruby on Rails <[EMAIL PROTECTED]>
Date: Mar 27, 2006 1:31 PM
Subject: [Ruby on Rails] #4440: Use of block args as assignment should go
To: [EMAIL PROTECTED]
#4440: Use of block args as assignment should go
-------------------------+--------------------------------------------------
Reporter: Ulysses | Owner: [EMAIL PROTECTED]
Type: enhancement | Status: new
Priority: normal | Milestone: 1.x
Component: RailTies | Version: 1.1.0 RC1
Severity: minor | Keywords:
-------------------------+--------------------------------------------------
This ticket is to address the use of block args to perform assignment to
hashes or arrays. For example: Proc.new {|options[:port]|}
On the assumption that this format will be deprecated, we are moving to
eliminate Rails' use of it. This will also bring Rails closer to
compatibility with JRuby.
The following message by Charles O Nutter spurred this ticket:
{{{
We in the JRuby project are working to get Rails to work successfully.
However, the array-indexed block parameter is not currently supported in
JRuby:
x = {}
[1,2].each {|x[:foo]|}
This is not used extensively in the Rails code, but it's used enough to
cause things to break in JRuby. We have been modifying the above to use a
temporary local variable, but obviously it's not ideal. I emailed the Ruby
Core list to ask how this behavior is implemented in C Ruby, and Matz's
response (below) seems to indicate that it will eventually be unsupported.
So my question is this: Would it not be reasonable to eliminate the few
uses of this unusual block parameter format right now? Of course I have
selfish motives; this behavior is a bit unusual and we would rather not
have to implement it if it will go away in the future. However, we want
very much the ability to run Rails in JRuby, and if we must we must.
}}}
--
Ticket URL: <
http://dev.rubyonrails.org/ticket/4440>
Ruby on Rails <http://dev.rubyonrails.org/>
--
Charles Oliver Nutter @
headius.blogspot.com
JRuby Developer @ jruby.sourceforge.net
Application Architect @ www.ventera.com
