3 ms·

You also lose information, because @1 and @2 magically appear. With || notation you have to explicitly spell out, beforehand, exactly how many variables will be

You also lose information, because @1 and @2 magically appear. With || notation you have to explicitly spell out, beforehand, exactly how many variables will be in the block. tuple.collect{ |x,y,z| [x * 3, y * 3, z * 3] } is better than tuple.collect{ [@1 * 3, @2 * 3, @3 * 3] } because with the latter, I need to know in my head that there will be three parameters. The more I read about this syntax the worse I feel about it.

yebyen 8y ago
I don't buy this argument. This is syntactically valid ruby, current state: tuple.collect{ |x,y,z| [x * 3, y * 3] } and so is this: tuple.collect{ |y,z| [x * 3, y * 3, z * 3] } The last one will generate a runtime error (unless "x" is already defined in the closed-over scope the block exists inside of, in that case it might be valid and correct.) But both are valid Ruby expressions. Neither are less inscrutable than: tuple.collect{ [@1 * 3, @2 * 3, @3 * 3] } This expression will return nil for @3 if only two arguments are passed in, again it's a perfectly valid Ruby expression, and you'll get a runtime error from inside of the block in this case, just like the pre-existing standard block syntaxes. It's up to the author of the code to create readable constructions that aren't misleading or confusing. There's no reason why this tool is innately bad, more tools can only make it more likely that the author will find an expressive and clear way to say exactly what they're doing without writing something confusing or redundant. From a language purist perspective, these are all very good reasons not to use Ruby at all. I don't think that adding numbered positional params makes it worse in any objective sense.
vidarh 8y ago
Except you don't. [1,2,3].collect{|x,y,z| ... } is perfectly valid ruby if "..." is an expression that does not blow up when y and z are nil. Likewise [[1,2,3]].collect{|x,y| [x,y]} is perfectly valid even though 3 will not get assigned to anything. So you're being forced to spell out which arguments you want to be able to reference, which is probably related to what it will get passed, but not required to be. So if you don't know how many parameters there will be, you're in trouble either way.

yebyen 8y ago

I don't buy this argument. This is syntactically valid ruby, current state: tuple.collect{ |x,y,z| [x * 3, y * 3] } and so is this: tuple.collect{ |y,z| [x * 3, y * 3, z * 3] } The last one will generate a runtime error (unless "x" is already defined in the closed-over scope the block exists inside of, in that case it might be valid and correct.) But both are valid Ruby expressions. Neither are less inscrutable than: tuple.collect{ [@1 * 3, @2 * 3, @3 * 3] } This expression will return nil for @3 if only two arguments are passed in, again it's a perfectly valid Ruby expression, and you'll get a runtime error from inside of the block in this case, just like the pre-existing standard block syntaxes. It's up to the author of the code to create readable constructions that aren't misleading or confusing. There's no reason why this tool is innately bad, more tools can only make it more likely that the author will find an expressive and clear way to say exactly what they're doing without writing something confusing or redundant. From a language purist perspective, these are all very good reasons not to use Ruby at all. I don't think that adding numbered positional params makes it worse in any objective sense.

vidarh 8y ago

Except you don't. [1,2,3].collect{|x,y,z| ... } is perfectly valid ruby if "..." is an expression that does not blow up when y and z are nil. Likewise [[1,2,3]].collect{|x,y| [x,y]} is perfectly valid even though 3 will not get assigned to anything. So you're being forced to spell out which arguments you want to be able to reference, which is probably related to what it will get passed, but not required to be. So if you don't know how many parameters there will be, you're in trouble either way.