Hi everyone,
I would like to know why the following code does not work :
class A
def A.
result = self.new( *args )
if block
yield result
result.end
end
return result
end
def end()
puts “end”
end
end
A[] do |a|
puts “a #{a.inspect}”
end
When I want to execute this script, the interpreter outputs the
following error :
d:/DEV/XRVG/bug.rb:18: parse error, unexpected kDO, expecting $
A[] do |a|
If I write “A.[] do |a|” instead of “A[] do |a|”, it is OK and
outputs:
a #<A:0x28ee264>
end
Any idea ?
Any help appreciated !! Thanks in advance.
On Jan 12, 2008, at 10:54 AM, blondinet wrote:
Any idea ?
[] method can’t take block unless you do
A.send ‘[]’ do
end
a @ http://drawohara.com/
On 12 jan, 22:00, “ara.t.howard” [email protected] wrote:
–
sleep is the best meditation.
h.h. the 14th dalai lama
Thanks for your response. However, I do not really understand why such
a behavior : for me, Class[] is just a shortcut for Class.[], which is
just a shortcut for Class.send ‘[]’ … Where am I wrong ?
blondinet wrote:
–
sleep is the best meditation.
h.h. the 14th dalai lama
Thanks for your response. However, I do not really understand why such
a behavior : for me, Class[] is just a shortcut for Class.[], which is
just a shortcut for Class.send ‘[]’ … Where am I wrong ?
Ruby’s parser doesn’t allow a block to follow [].
On 12 jan, 23:06, Tim H. [email protected] wrote:
a @http://drawohara.com/
–
RMagick:http://rmagick.rubyforge.org/
RMagick 2:http://rmagick.rubyforge.org/rmagick2.html
Hello Tim, thank you for your response. However I think it is a bit
erroneous, since in my example, “A.[] do |a|” works !!
Anyway, I will go with it, even if it is the first time that I find
Ruby a bit incoherent, and I would like to know why … (sigh)
P.S : by the way, Tim, thanks for your work on RMagick, it is quite
helpfull !!
You may find interesting the following link
http://xrvg.rubyforge.org/,
even if it just a beginning 
On Jan 12, 2008 11:54 AM, blondinet [email protected] wrote:
result.end
A[] do |a|
puts “a #{a.inspect}”
end
That is interesting. With 1.8.6, I get results like this…
irb(main):001:0> class C
irb(main):002:1> def []
irb(main):003:2> yield
irb(main):004:2> end
irb(main):005:1> end
=> nil
irb(main):006:0 c = C.new
=> #<C:0x2dfac1c>
irb(main):007:0> c[]
LocalJumpError: no block given <<<interesting part
from (irb):3:in `[]’
from (irb):7
irb(main):008:0> c[] {}
SyntaxError: compile error
(irb):8: syntax error, unexpected ‘{’, expecting $end
c[] {}
^
from(irb):8
irb(main):009:0> c.[] {}
=> nil
Bug maybe? I can’t think of a reason why the parser would need to
separate [] from .[]
Hmm…
Todd
On 13 jan, 10:56, Todd B. [email protected] wrote:
def A.
end
irb(main):002:1> def []
irb(main):008:0> c[] {}
Hmm…
Todd
Thanks Todd for your analysis.
Your example is even striking than mine, and I share your opinion on
this strange “feature” : that a block is required and cannot be given
with the same syntax seems to me a bit “ugly”.
Any other opinion ? As a beginner on this forum, I do not know yet
what to do with this …
On Jan 13, 2008 6:24 PM, blondinet [email protected] wrote:
class A
def end()
from (irb):3:in `[]'
Bug maybe? I can’t think of a reason why the parser would need to
what to do with this …
As this behavior is inherited in 1.9 too :(, I’d say somebody cross
posting this to ruby-core maybe.
Personally I’d love to have that changed.
Cheers
Robert
–
http://ruby-smalltalk.blogspot.com/
Whereof one cannot speak, thereof one must be silent.
Ludwig Wittgenstein
On Jan 13, 8:16 pm, Robert D. [email protected] wrote:
Personally I’d love to have that changed.
[] is an operator (the index operator). I would expect [] to have
higher precedence than anything that follows it. Although implemented
as such, it should not be seen as a function call, IMHO.
If
foo[i] #=> 42
Then I would expect
foo[i] { }
to be the same as
42 { }
which makes little sense.
On Jan 14, 2008 9:01 AM, Lars [email protected] wrote:
Then I would expect
foo[i] { }
to be the same as
42 { }
which makes little sense.
So operators that you can redefine and execute as a method cannot
except a block as a general rule of thumb?
I would think foo[i] { } would be parsed as (foo[i] { }) as a single
piece, especially if you defined it to receive a block.
On Jan 14, 2008, at 10:25 AM, Todd B. wrote:
So operators that you can redefine and execute as a method cannot
except a block as a general rule of thumb?
I would think foo[i] { } would be parsed as (foo[i] { }) as a single
piece, especially if you defined it to receive a block.
Ruby is smart so you don’t have to be. But here, it works against us.
foo. do
puts 42
end
Mess around with removing the dot, putting the i in between the
brackets, etfc.
On Jan 14, 2008 4:01 PM, Lars [email protected] wrote:
I am not sure I follow you, but as an anecdote I once wrote the
following method definition
def + x, &blk
…
end
when I realized that I could not go
anything + 42 { 42 }
I was quite disappointed …
Robert
–
http://ruby-smalltalk.blogspot.com/
Whereof one cannot speak, thereof one must be silent.
Ludwig Wittgenstein
On Jan 14, 5:22 pm, Robert D. [email protected] wrote:
I am not sure I follow you
I’m just trying to say that I don’t think that what you suggest is
intuitive behaviour to everyone. I personally think that it doesn’t
make sense from a syntax point-of-view. Operators and function calls
are syntactically different things. Function calls take optional block
arguments, operator don’t. I doubt its even possible to construct an
unambigious syntax.
when I realized that I could not go
anything + 42 { 42 }
I was quite disappointed …
Consider
def something; 42; end
anything + something { 42 }
Would the block be passed to ‘something’ or the ‘+’?
On Jan 15, 2008 11:15 AM, Lars [email protected] wrote:
On Jan 14, 5:22 pm, Robert D. [email protected] wrote:
I am not sure I follow you
I’m just trying to say that I don’t think that what you suggest is
intuitive behaviour to everyone. I personally think that it doesn’t
make sense from a syntax point-of-view. Operators and function calls
are syntactically different things. Function calls take optional block
arguments, operator don’t. I doubt its even possible to construct an
unambigious syntax.
Sorry but that just does not make sense to me…
Would the block be passed to ‘something’ or the ‘+’?
Well this is for the parser to decide, right? But
a + s &b being a.send(:+,s,&b) would make more sense as we still could
easily override this via the following
a + s(&b)
a + s(){}
a + (s {})
Robert
–
http://ruby-smalltalk.blogspot.com/
Whereof one cannot speak, thereof one must be silent.
Ludwig Wittgenstein