Re: PDD: Conventions and Guidelines for Perl Source Code
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. Hoisting implementation details into the name defeats that abstraction. I really, *really* don't want to hide very much of the implementation details at the C code level. We do that right now, and it makes for a twisty maze of macros, all alike. And the resulting C code bears very little resemblance to what's actually written. (I've seen size increases of two orders of magnitude--20 characters of source text become 2K or more after macro expansion) But isn't that the whole point of macros? Who wants to see the same 2K of code at the top of every function? Cheers, -Ben -- Benjamin Sugars [EMAIL PROTECTED]
Re: PDD: Conventions and Guidelines for Perl Source Code
Dave Mitchell wrote: quote All entities should be prefixed with the name of the subsystem they appear in, eg Cpmc_foo(), Cstruct io_bar. They should be further prefixed with the word 'perl' if they have external visibility or linkage, /quote Duh! Missed it. Thanks. Alan Burlison
Re: PDD: Conventions and Guidelines for Perl Source Code
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 people that Something Funny is Going On Here. Oh well, I surrender... 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 it has turned from abstraction into obfustification. Alan Burlison
Re: PDD: Conventions and Guidelines for Perl Source Code
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 it has turned from abstraction into obfustification. As I have said more than once before, excessive use of macros can be a performance killer. It is better to have slabs of common stuff in real function (which is cached) rather than replicated all over the place. That is the style I use in my own (whoops sorry, TI's) code and it does not seem to hurt even on X86 CISC machines. -- Nick Ing-Simmons who is looking for a new job see http://www.ni-s.u-net.com/
Re: PDD: Conventions and Guidelines for Perl Source Code
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 may declare stuff and thus needs to be at the start of a block should be prefixed with CDECL_, eg CDECL_SAVE_STACK So dSP would now be DECL_SP. And we dont specially mark macros which may use impicitly declared variables ???
