Back in the mists of time (May 29th), I solicited comments on my second
draft of the deeply thrilling "Conventions and Guidelines for Perl
Source Code". There were various contributions, but having more interesting
things to do [watching paint dry etc - Ed], I never got round to incorporating
them
At 07:45 AM 5/11/2001 -0700, Dave Storrs wrote:
>On Wed, 9 May 2001, Larry Wall wrote:
>
> > Dave Mitchell writes:
> > : My thinking behind "if fails on one, avoid on all" was that if it failed
> > : on at least one, then it may well fail on others that you dont have
> access
> > : to - either
On Wed, 9 May 2001, Larry Wall wrote:
> Dave Mitchell writes:
> : My thinking behind "if fails on one, avoid on all" was that if it failed
> : on at least one, then it may well fail on others that you dont have access
> : to - either now or in the future, and thus perhaps isnt as good an optimi
Since we all seem to be agreed that macros that Do Strange Things are evil,
but are a necessary evil in certain extensibility situations,
and since Larry choked on my choice of naming scheme for macros
which declare variables for you, here's a slighly more modest proposal:
=item *
A macro that m
Alan Burlison <[EMAIL PROTECTED]> writes:
>
>I strongly agree. The current macro mayhem in perl is an utter abomination,
>and drastically reduces the maintainability of the code. I think the
>performance argument is largely specious, and while abstraction is a
>laudable aim, in the case of perl
Dave Mitchell wrote:
> My main objection to dSP et al is that it represents the innermost circle
> of the hell that is Perl 5 macros. Stuff like this is totally bemusing to
> the newcomer:
>
> dPOPPOPnnrl;
> if (right == 0.0)
>
> I was just trying think of ways of altering peop
Dave Mitchell wrote:
>
> All entities should be prefixed with the name of the subsystem they appear
> in, eg C, C. They should be further prefixed
> with the word 'perl' if they have external visibility or linkage,
>
Duh! Missed it. Thanks.
Alan Burlison
On Wed, 9 May 2001, Dan Sugalski wrote:
> At 09:33 AM 5/9/2001 -0700, Larry Wall wrote:
>
> >I think that's silly. You misuse a variable that requires an auto, the
> >compile dies, that's all. And macros can be very useful for an abstraction
> >layer that intended to *hide* the implementation.
> No, that's not the point of macros. When you find you have 5, or 10, or 20
> levels of substitution, it means you have a real problem somewhere. Macros
> should be simple. Fancy macros, or lots of little nested macros, show a
> lack of thought about the long term. It also contributes really b
At 09:36 PM 5/9/2001 -0400, Benjamin Sugars wrote:
>On Wed, 9 May 2001, Dan Sugalski wrote:
>
> > At 09:33 AM 5/9/2001 -0700, Larry Wall wrote:
> >
> > >I think that's silly. You misuse a variable that requires an auto, the
> > >compile dies, that's all. And macros can be very useful for an
> a
At 09:33 AM 5/9/2001 -0700, Larry Wall wrote:
>Dave Mitchell writes:
>: | anyone know precisely what the following means?
>:
>: "K&R" style for indenting control constructs
>
>Strictly speaking, it means you always put the opening bracket on the
>same line as the keyword, and only worry about lini
Dave Mitchell writes:
: My thinking behind "if fails on one, avoid on all" was that if it failed
: on at least one, then it may well fail on others that you dont have access
: to - either now or in the future, and thus perhaps isnt as good an optimisation
: as you figured. The other way would to b
Larry Wall writes:
: Dave Mitchell writes:
: : | anyone know precisely what the following means?
: :
: : "K&R" style for indenting control constructs
:
: Strictly speaking, it means you always put the opening bracket on the
: same line as the keyword, and only worry about lining up the closing
:
Larry Wall <[EMAIL PROTECTED]> wrote:
> Dave Mitchell writes:
> : | my personal pet peeve: death to dSP and friends !!
...
> I think that's silly. You misuse a variable that requires an auto, the
> compile dies, that's all. And macros can be very useful for an abstraction
> layer that intended t
> : For example, if your struct eventually needs more than
> : 32 flags, can it be gracefully expanded to more than a single word of
> : flags? Bear in mind that there may be code in other people's Perl
> : extensions and code that Perl itself is embedded in, all of which
> : may be using your stu
Dave Mitchell writes:
: | anyone know precisely what the following means?
:
: "K&R" style for indenting control constructs
Strictly speaking, it means you always put the opening bracket on the
same line as the keyword, and only worry about lining up the closing
bracket:
: | my personal pet peev
> I see nothing about namespacing, e.g. Perl_
All entities should be prefixed with the name of the subsystem they appear
in, eg C, C. They should be further prefixed
with the word 'perl' if they have external visibility or linkage,
eg
perlpmc_foo()
struct perlio_bar
typedef struct perlio_bar
I see nothing about namespacing, e.g. Perl_
Alan Burlison
Here's something I promised ages ago, but life got in the way:
first draft of the PDD on all things related to coding: comments,
code structure, naming conventions etc etc. Not as exciting as a Schwartzian
Transform perhaps, but still needs discussion.
I have included comments on bits I'm not sur
19 matches
Mail list logo
