Will 2.0 stop issuing this warning for
x.foo ( arg )
It affects a very common code style.
How about 1.8.x ?
As of semi-latest 1.9, at least, there is no warning issued, but I
think that the results might not be what you expect:
mark@imac% ruby -vwe’puts(0…9).to_a.join; puts (0…9).to_a.join(“:”)’
ruby 1.6.8 (2002-12-24) [powerpc-darwin7.0]
-e:1: warning: puts (…) interpreted as method call
0…9
0…9
mark@imac% ruby -vwe’puts(0…9).to_a.join; puts (0…9).to_a.join(“:”)’
ruby 1.9.0 (2004-02-21) [powerpc-darwin]
-e:1: warning: (…) interpreted as grouped expression
0…9
0:1:2:3:4:5:6:7:8:9
Apparently putting a space there was deprecated because it was marked
for a change.
–Mark
···
On Apr 7, 2004, at 10:44 AM, Its Me wrote:
Will 2.0 stop issuing this warning for
x.foo ( arg )It affects a very common code style.
How about 1.8.x ?
As I recall, the warning was added in 1.8 because that sort of style was being
deprecated.
If that warning is no longer issued in 2.0, it will probably mean that
x.foo ( arg1, arg2, ... )
is no longer equivalent to
x.foo(arg1, arg2, ...)
Which means your coding style won’t work at all anymore instead of merely
generating warnings (that is, if it runs at all, it probably won’t run like
you expect).
- Dan
···
On Wednesday 07 April 2004 1:44 pm, Its Me wrote:
Will 2.0 stop issuing this warning for
x.foo ( arg )It affects a very common code style.
How about 1.8.x ?
oops! sorry for replying to my own post, but…
As of semi-latest 1.9, at least, there is no warning issued
no, I’m not really that inobservant. I intended to say that that
particular warning is not issued. bonks self on head That’s what I
get for dashing the email off so quickly…
Note however that the warning might be removed in the future, if it is
decided that this should be considered a normal use…
–Mark
···
On Apr 7, 2004, at 11:06 AM, Mark Hubbart wrote:
x.foo ( arg )As I recall, the warning was added in 1.8 because that sort of style was
being
deprecated.
I hope that’s not the case. I’d rather be told it is a limitation in the
current parser or some such.
It’s hard to argue that
x.foo( y.bar( z.baz )))
makes better reading breaks for the eye than
x.foo ( y.bar ( z.baz )))
The different is even more glaring if you remove the spaces after the “(”
x.foo(y.bar(z.baz )))
Vs.
x.foo (y.bar (z.baz )))
Anyone know for sure? Matz?
Thanks …
Hi,
x.foo ( arg )As I recall, the warning was added in 1.8 because that sort of style was
being
deprecated.I hope that’s not the case. I’d rather be told it is a limitation in the
current parser or some such.It’s hard to argue that
x.foo( y.bar( z.baz )))
makes better reading breaks for the eye than
x.foo ( y.bar ( z.baz )))The different is even more glaring if you remove the spaces after the “(”
x.foo(y.bar(z.baz )))
Vs.
x.foo (y.bar (z.baz )))Anyone know for sure? Matz?
I recall Matz having addressed this in a couple threads, but,
this is all I’ve been able to find so far:
http://ruby-talk.org/84104
Regards,
Bill
···
From: “Its Me” itsme213@hotmail.com
Personally, I don’t see much of a difference. That’s me, though.
There’s also the issue that adding a space can mean different things. For
example:
def foo(lst)
p lst
lst
end
foo(1..5).to_a.reverse #=> prints 1..5
foo (1..5).to_a.reverse #=> prints [5, 4, 3, 2, 1]
The Ruby interpreter handles everything I can currently come up with correctly
(from my point of view), so I don’t think it’s an interpreter issue. The
parser can figure out what happens unambiguously, but it may be ambiguous to
a human (the second foo above seems ambiguous to me unless you specify that
all parentheses must immediately follow function calls if you’re using them).
Cheers.
- Dan
···
On Wednesday 07 April 2004 4:34 pm, Its Me wrote:
x.foo ( arg )As I recall, the warning was added in 1.8 because that sort of style was
being
deprecated.
I hope that’s not the case. I’d rather be told it is a limitation in the
current parser or some such.It’s hard to argue that
x.foo( y.bar( z.baz )))
makes better reading breaks for the eye than
x.foo ( y.bar ( z.baz )))