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 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 b
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 wou
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 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 coupl
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<
: > >...
: > >> }
: >
: > Wh
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 #{}:
>
> - p
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 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 constru
> "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 wh
"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 fai
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 constru
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 #{}. Incide
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 macr
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
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
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 t
17 matches
Mail list logo
