On Mon, Aug 21, 2006 at 12:06:36AM +0100, Andrew Suffield wrote:
On Sun, Aug 20, 2006 at 03:55:56PM -0600, Luke Palmer wrote:
Why would you care about introducing a new lexical scope? You would
care about that if you used a variable you declared in the commented
code in the code below
I think this is not even a metaprogramming issue so much as a
programming environment one. I mean, if your editor doesn't make it
easy to stick a # at the beginning of a bunch of lines with one
action, and likewise remove them later, you need to get a new editor.
:)
On 8/21/06, Joshua Hoblitt
On Sat, Aug 19, 2006 at 02:26:28AM +, Luke Palmer wrote:
On 8/19/06, Aaron Crane [EMAIL PROTECTED] wrote:
You don't actually need a macro in that case:
if 0 { q
...
}
Which, of course, eliminates the original desire to have a
code-commenting construct where you just
On 8/20/06, Joshua Hoblitt [EMAIL PROTECTED] wrote:
This is exactly the type of construct that I had in mind. A couple of
questions. Is code inside of a #{}:
- parsed and required to be syntacticly correct?
No. It's a comment. # followed by one or more open bracket characters
creates a
On Sun, Aug 20, 2006 at 10:50:31AM -1000, Joshua Hoblitt wrote:
#{
if $baz {
$foo.bar
}
}
To uncomment, remove the # before the {.
This is exactly the type of construct that I had in mind. A couple of
questions. Is code inside of a #{}:
- parsed and required
On Sun, Aug 20, 2006 at 10:50:31AM -1000, Joshua Hoblitt wrote:
: On Sat, Aug 19, 2006 at 02:26:28AM +, Luke Palmer wrote:
: On 8/19/06, Aaron Crane [EMAIL PROTECTED] wrote:
: You don't actually need a macro in that case:
:
: if 0 { q
: ...
: }
:
: Which, of course,
On 8/20/06, Andrew Suffield [EMAIL PROTECTED] wrote:
On Sun, Aug 20, 2006 at 10:50:31AM -1000, Joshua Hoblitt wrote:
#{
if $baz {
$foo.bar
}
}
To uncomment, remove the # before the {.
This is exactly the type of construct that I had in mind. A couple of
questions.
On 8/20/06, Luke Palmer [EMAIL PROTECTED] wrote:
Well, I think you are being too picky.
[snip snarky sarcastic rant]
Hmm, perhaps I'm feeling edgy. Or maybe some of the comments reminded
me of those rediculously long, whiny threads. Anyway, that was
un-called-for.
Luke
On Sun, Aug 20, 2006 at 03:55:56PM -0600, Luke Palmer wrote:
The important question here is this one:
- when 'uncommented', is it a no-op?
Which isn't true for #{}/{}, because {} introduces new lexical
scope.
Why would you care about introducing a new lexical scope? You would
care
On Sat, Aug 19, 2006 at 02:26:28AM +, Luke Palmer wrote:
On 8/19/06, Aaron Crane [EMAIL PROTECTED] wrote:
You don't actually need a macro in that case:
if 0 { q
...
}
Which, of course, eliminates the original desire to have a
code-commenting construct where you just
Stuart Cook schreef:
Larry Wall:
if 0 {
...
}
The one disadvantage of that approach is that it will break if the
commented-out code temporarily fails to compile.
How frequent does that happen?
And in that case s/if 0/\#/, as Luke mentioned.
And if the compile failure has to
Stuart Cook schreef:
Larry Wall:
if 0 {
...
}
The one disadvantage of that approach is that it will break if the
commented-out code temporarily fails to compile.
How frequent does that happen?
All the time. I often comment out bits of code while I'm refactoring or
It occurred to me that other day that in our in house C code we
somewhat frequently use an idiom that's not easily translated into Perl
5. Our rule is that if your commenting out more then 1 or 2 lines of
code that you wrap it in a CPP if statement. The logic being that
if you haven't deleted
On Fri, Aug 18, 2006 at 11:58:20AM -1000, Joshua Hoblitt wrote:
: It occurred to me that other day that in our in house C code we
: somewhat frequently use an idiom that's not easily translated into Perl
: 5. Our rule is that if your commenting out more then 1 or 2 lines of
: code that you wrap
On 8/19/06, Larry Wall [EMAIL PROTECTED] wrote:
if 0 {
...
}
The one disadvantage of that approach is that it will break if the
commented-out code temporarily fails to compile. If that's a
problem, though, you could always write your own macro.
Stuart Cook
Stuart Cook writes:
On 8/19/06, Larry Wall [EMAIL PROTECTED] wrote:
if 0 {
...
}
The one disadvantage of that approach is that it will break if the
commented-out code temporarily fails to compile. If that's a
problem, though, you could always write your own macro.
You don't
On 8/19/06, Aaron Crane [EMAIL PROTECTED] wrote:
You don't actually need a macro in that case:
if 0 { q
...
}
Which, of course, eliminates the original desire to have a
code-commenting construct where you just change the 0 to a 1. After
all, we already have #{}.
17 matches
Mail list logo
