in reply to Use of 'our' considered harmful

As the author of a couple of modules on CPAN I know that moving too quickly to use new features/constructs is a bad idea. Some users of my modules are still at 5.004. A while ago I had someone contact me trying to build sybperl with 5.002.

But - there are also issues with not using new features. There is a balance to strike, and it all depends on the particular module's code to find out what perl version/features should be supported.

BTW - the same can be said for C code. The C/XS portion of my modules is still, by and large, K&R level code. This is mainly due to having this as the lowest common denominator when the modules were written (f.ex. SunOS 4.x cc didn't understand prototypes). So using new features of tools isn't only a problem of perl.

Michael

Replies are listed 'Best First'.
Re^2: Use of 'our' considered harmful
by tantarbobus (Hermit) on Sep 24, 2004 at 10:50 UTC
    I actually like the K&R prototypes beter than the ansi:
    int foo(this, that, these) char *this; char *that; char *these; { } /* Is much nicer than: */ int foo(char this, char that, char those) { }

      The point in ANSI prototypes is that when you use them, any call to the function will actually convert the parameters to whatever type the prototye says.

      More clearly, the K&R style declaration of arguments (which is not a prototype btw) say only what the function pops off the stack, but not what the caller pushes to the stack. If, however, a function has an ANSI C prototype (and it's included in wherever you call the function from), the C compiler will automatically convert parameters to whatever the prototye says, and will warn you if you call the function with an incompatible number or type of parameters.

        I meant declaration ;). But My point was more about the syntax. I like the former better because, for me, it is just easier to scan.
      Nothing to stop you writing
      int foo ( char *this, char *that, char *these ) { ... }
      FWIW... :-)

      Michael

      In both cases the type (and most of the modifiers and other cruft) is on the wrong side of the variable. Does anyone think "and now I'm going to need an int, let's call it counter"? I think not. Normal people say to themselves "and now I'm going to need a counter, an int will be enough".

      Not speaking about the mess with pointers to functions and functions returning pointers etc. int *foo() vs. int (*)foo() anyone?

      Jenda
      Always code as if the guy who ends up maintaining your code will be a violent psychopath who knows where you live.
         -- Rick Osborne

        I'm not normal. :-) Because of this, I always make mistakes in SQL when creating tables.