D
David A. Black
Hi --
(So your keyboard *does* have parens!
I think this is different, in the sense that
const char *cp;
declares "*cp" ("cp dereferenced by one level") to be of type const
char -- and then it's simply used that way. So it's consistent; *cp
is always of the same type, and * always means the same thing.
It's true that the two &'s in your example mean different things, so
one could argue that there's strangeness. But they're syntactically
quarantined from each other, so there's no unclarity.
However, if & were a synonym for lambda, different &'s would start to
mingle unclearly with each other. Specifically, & would then mean
both "make a Proc object from the following block" (lambda {}) and
"make a block from the following Proc object" (some_method &a_proc).
And then this:
def some_method(*args)
end
some_method &{}
could be either
some_method &lambda {}
or
some_method(lambda {})
I know that parentheses for method arguments are being encouraged
(required?) in upcoming Rubies, but I still think this would end up
getting tied in knots. To use another C analogy: it's almost like
using * and * instead of * and &, and counting on circumstantial or
semantic things to disambiguate them. (Not an exact analogy but
indicative of what I think might be the problems.)
David
it's no stranger than this to me
jib:~ > cat a.rb
def method █ m █ end
def m █ block.call; end
method{ puts 42 }
jib:~ > ruby a.rb
42
and feels alot like
const char *cp = "foobar";
printf ("%c\n", *cp);
(So your keyboard *does* have parens!
I think this is different, in the sense that
const char *cp;
declares "*cp" ("cp dereferenced by one level") to be of type const
char -- and then it's simply used that way. So it's consistent; *cp
is always of the same type, and * always means the same thing.
It's true that the two &'s in your example mean different things, so
one could argue that there's strangeness. But they're syntactically
quarantined from each other, so there's no unclarity.
However, if & were a synonym for lambda, different &'s would start to
mingle unclearly with each other. Specifically, & would then mean
both "make a Proc object from the following block" (lambda {}) and
"make a block from the following Proc object" (some_method &a_proc).
And then this:
def some_method(*args)
end
some_method &{}
could be either
some_method &lambda {}
or
some_method(lambda {})
I know that parentheses for method arguments are being encouraged
(required?) in upcoming Rubies, but I still think this would end up
getting tied in knots. To use another C analogy: it's almost like
using * and * instead of * and &, and counting on circumstantial or
semantic things to disambiguate them. (Not an exact analogy but
indicative of what I think might be the problems.)
David