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 peeve: death to dSP and friends !!
:
: Macros must never define or implicity use auto variables unless it
: is essential for extensibility. In this case, defining macros should
: be prefixed with C<DEFVAR_>, and macros which use said variables should
: be prefixed with C<VAR_>, eg
:
: #define DEFVAR_save_stack struct Stack *oldsp = sp;
: #define VAR_restore_stack sp = oldsp;
:
: This then at least provides some warning to the programmer that things
: are being done behind his/her/its back.
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. Hoisting implementation
details into the name defeats that abstraction.
The whole point of dSP and friends was to make it easier to switch to
inline threaded code if we felt like it, in which case all bets are off
as to which variables are auto.
: =head2 Extensibility
:
: If Perl 5 is anything to go by, the lifetime of Perl 6 will be at least
: seven years. During this period, the source code will undergo many major
: changes never envisaged by its original authors - cf threads, unicode
: in perl 5. To this end, your code should make as few assumptions as
: possible.
Any statement that contains the phrase "as X as possible" is very
likely one-sided. Balance is usually necessary. The fact of the
matter is that code that makes as few assumptions as possible runs
incredibly slow. So it's not possible to make as few assumptions as
possible. (Well, it is, but we don't want to do that.)
: 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 stuff. Or there may be other distributions of Perl
: using your code. You may find it rather difficult to persuade all these
: other programmers to modify their code due to your lack of foresight.
Given this sort of directive, many programmers would go off and invent
a general property system that is completely general and runs like a
dog. I guess the real problem here is that we aren't saying what
*kinds* of assumptions are bad. One of the assumptions we need to
avoid is that abstractions in the compiler are necessarily reflected in
complications at runtime. Using the example given, if you need more
than 32 flags, and you've abstracted your flags with macros, then it's
pretty simple to redirect some of the flags to a different flag word
without introducing a level of indirection at run-time.
Sorry, I know this point is actually balanced out later in the document,
but it hit a hot button.
: If you do put an optimisation in, time it on as many architectures
: as you can, and reject it if it slows down on any of them! And remember
: to document it.
Or disable the optimization on that architecture, to get the benefit of
it elsewhere, balancing the benefits of the small code fork against
the benefits of not forking. When in Rome, do as the Romans would do
if they weren't Roman and just visiting.
Larry
