|
in reply to More than One Line Comment
Wouldn't it be nice if the sequence '#{\n' caused the block that begins with the open brace became a nop. So quick and simple to comment out/uncomment an if clause, or the body of a for loop, or an entire subroutine:
...
if( .. ) #{
...
}
...
while( ... ) #{
...
}
Literally, a block comment :)
Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
Lingua non convalesco, consenesco et abolesco. -- Rule 1 has a caveat! -- Who broke the cabal?
"Science is about questioning the status quo. Questioning authority".
The "good enough" maybe good enough for the now, and perfection maybe unobtainable, but that should not preclude us from striving for perfection, when time, circumstance or desire allow.
|
Re^2: More than One Line Comment
by cees (Curate) on May 11, 2005 at 16:26 UTC
|
It might be easy, but it is also very subtle and not very noticable. I guess a good syntax highlighter could solve that, but it looks like something that would be easy to overlook while debugging.
I comment out blocks very quickly using my editor. In Vim I just cursor to the { or the }, then hit Shift-V % .c and the entire block is commented. To uncomment, use the same procedure except use .C instead of .c.
The .c command is provided by the BlockComment plugin found here. The Shift-V starts line by line highlighting and the % finds the matching bracket to the one you are currently on or near. You could probably write a simple macro that does the same thing in one or two keypresses as well.
- Cees
| [reply] |
|
|
Needless to say, but I don't use vim or emacs. My editor can do that too, but it's not the point.
The subtlety of this is that it comments/uncomments a block. A block as defined by the language.
Not some manually chosen grouping of an artificial concept of 'lines';
Your point that it could be overlooked is valid, but if a block is going to be commented out (semi-)permenantly, then I would either put it into a pod comment, or physically remove it. The use of being able to comment out a block in a block-strucured language would be to test it's effect in the short term. A quick "what if" check whilst debugging. Easy to do and undo.
If, having tried the idea out, you decided to make it semi-permenant, then you could go back and use a macro to make it more distinctive.
Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
Lingua non convalesco, consenesco et abolesco. -- Rule 1 has a caveat! -- Who broke the cabal?
"Science is about questioning the status quo. Questioning authority".
The "good enough" maybe good enough for the now, and perfection maybe unobtainable, but that should not preclude us from striving for perfection, when time, circumstance or desire allow.
| [reply]
[d/l] |
Re^2: More than One Line Comment
by Roy Johnson (Monsignor) on May 11, 2005 at 20:14 UTC
|
If you can identify the beginning of the block yourself (and the opening brace is at the end of the line, as you stipulate), you can stick
0 and do { # in front of it and get the block commented out. It doesn't let you get away with syntax errors in it, but I would think that a block would have to be properly formed for block comments to work, anyway.
...
0 and do { #if (whatever) {
...
}
...
0 and do { #while (whatever) {
...
}
Caution: Contents may have been coded under pressure.
| [reply]
[d/l]
[select] |
Re^2: More than One Line Comment
by salva (Canon) on Nov 17, 2005 at 12:17 UTC
|
if( 0 and ... ) {
...
}
...
while( 0 and ... ) {
...
}
| [reply]
[d/l] |
|
|
That's pretty good, but has the effect of also disabling any side effects of the conditional. Sometimes that's okay, but mostly you want the rest of the code to run normally and only disable the action within the block.
It also misses the all the other opportunities where the #{ ... } might work, from bareblocks to inline blocks to subroutine bodies. In fact anywhere where a scoping block can currently exist, if that block is preceded by a #, then the entire block would be made noop.
It even looks (to the non-expert source diver I am) as if it would be fairly easy to implement. There are some edge cases that would need to be dealt with if it were to be truely universal. For example, to work with the inline blocks of map and grep, it would need to replace the disabled block with a default behaviour. Eg. pass everything through for grep, and the input unchanged for map.
Dealing with non-core and user-defined map-like subs, (List::Util::reduce/first, etc), would be a problem, but then they need prototypes to function and there are a lot of dark corners surrounding protoyped subs; one more probably wouldn't hurt.
Any way you cut it, the absence of a proper multi-line comment is a thorn in the side of Perl 5 that I'd love to see corrected in Perl 6. I think the addition of a scoped-comment, one that works with the language structure rather than arbitrary lines, would be a unique and powerful feature of the new language.
The only good argument against it I've seen is the "not very obvious/visible", which as I outlined it above is very valid. However, I see no reason why the syntax shoudn't be extended to be "an open brace preceded by 1 or more #s with no intervening whitespace or other characters. That would allow for people who favour delimiting their comments in very obvious ways to do something like
if( ... )
######################################################################
+######{
...
}
## or
while( ... ) ########{
...
...
}
As programmers, our eyes are already tuned to pairing braces, and with proper indentation, it is fairly intuative to see the extent of the block(-comment).
Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
Lingua non convalesco, consenesco et abolesco. -- Rule 1 has a caveat! -- Who broke the cabal?
"Science is about questioning the status quo. Questioning authority".
In the absence of evidence, opinion is indistinguishable from prejudice.
| [reply]
[d/l]
[select] |
|
|
