3 ms·

Even though it's slower, I avoid the latter form as a matter of style. I think it's super important that if a method yields, it's shown in the method signature.

by SeoxyS 12y ago

Even though it's slower, I avoid the latter form as a matter of style. I think it's super important that if a method yields, it's shown in the method signature. Otherwise, your code won't be self-documenting, and it's going to cause weird and hard-to-debug bugs later on.

dragonwriter 12y ago
> Even though it's slower, I avoid the latter form as a matter of style. I think it's super important that if a method yields, it's shown in the method signature. Using &block in the signature does not indicate that the method yields, it indicates that the method reifies a Proc. To me, its a sign that the method does something which makes it likely that the passed block will be called outside of the usual lifetime of the called method. Now, it may be an issue that Ruby has no self-documenting signature element which indicates that a method expects a block for the purpose of yielding without reification, but overloading the signature element which is for reification doesn't really address that (and, destroys one element of self-documentation in order to create another one.)
- stormbrew 12y ago
  So, that the function reifies the block is not part of its interface, though, it's part of its implementation. If anything it's a problem that this implementation detail leaks out through the interface. Furthermore, if you pass it a block with & on the call-side, it's not really reifying a block anyways (even if there is still a performance penalty, which I've never checked), so it's not even true that's what it means in general. The truth is all functions take a block in ruby. Only some of them do anything with it. Given that, indicating that you take a block with the &block argument seems entirely reasonable to me, if you don't mind the performance hit.
aaviran 12y ago
I strongly agree. Code is read from top to bottom, and finding out that a method uses a block after reading through most of it, is confusing, whereas `&block` in the method signature clarifies that this method will do something with a block. The performance hit, as bad as it may be, is not something that should be a concern in many programs. After all, you are using Ruby...

by SeoxyS 12y ago

dragonwriter 12y ago

> Even though it's slower, I avoid the latter form as a matter of style. I think it's super important that if a method yields, it's shown in the method signature. Using &block in the signature does not indicate that the method yields, it indicates that the method reifies a Proc. To me, its a sign that the method does something which makes it likely that the passed block will be called outside of the usual lifetime of the called method. Now, it may be an issue that Ruby has no self-documenting signature element which indicates that a method expects a block for the purpose of yielding without reification, but overloading the signature element which is for reification doesn't really address that (and, destroys one element of self-documentation in order to create another one.)

stormbrew 12y ago
So, that the function reifies the block is not part of its interface, though, it's part of its implementation. If anything it's a problem that this implementation detail leaks out through the interface. Furthermore, if you pass it a block with & on the call-side, it's not really reifying a block anyways (even if there is still a performance penalty, which I've never checked), so it's not even true that's what it means in general. The truth is all functions take a block in ruby. Only some of them do anything with it. Given that, indicating that you take a block with the &block argument seems entirely reasonable to me, if you don't mind the performance hit.

aaviran 12y ago

I strongly agree. Code is read from top to bottom, and finding out that a method uses a block after reading through most of it, is confusing, whereas `&block` in the method signature clarifies that this method will do something with a block. The performance hit, as bad as it may be, is not something that should be a concern in many programs. After all, you are using Ruby...