I released my first module, Class::Trait to CPAN a week or so ago. But to be honest, I had always thought of it as a more pragma-ish module though, and had in the early stages called it trait rather than Class:Trait. Eventually though Class::Trait stuck, and it was released as that. But now as I am tweaking the code more, and experimenting with using the module, I am thinking it is more appropriate as a pragma, and maybe I should rename it as such.

Class::Trait does 90% of its work in the BEGIN phase, the other 10% in the INIT phase and provides no functions for any outside modules to call. It also does a whole lot of symbol table analysis & manipulation. To me that is a pragma. But I think Class::Trait is more appropraite as a pragma not just because of when and how it does it's work but also because I think the syntax would be cleaner. Consider the current state: 

use Class::Trait "TPrintable";

[download]
Versus the pragmatic name: 
use trait "TPrintable";

[download]
I know it is not a huge difference, but to me it just reads better and feels cleaner.

I am wondering how people feel about pragma-style module names compared to more "regular" module names. It seems that the pragmas section on the CPAN is one of the more sparsly populated areas, although I know this is only the registered ones. Am I just not seeing the bredth of pragmas out there, or are there really just not that many? When proposing a module name/namespace through the PAUSE web interface, pragmas are not even listed as a category, but as an interface style. Is there a reluctance out there to use/accept pragmas over "regular" modules? What do you all think?

-stvn

Replies are listed 'Best First'.
Re: RFC : Pragma vs. Module
by liz (Monsignor) on Mar 14, 2004 at 17:02 UTC
    Class::Trait does 90% of its work in the BEGIN phase, the other 10% in the INIT phase...

    Please note that if you depend on the INIT {} code block for your functionality, then you cannot use your module with mod_perl. You should at least provide an alternative way to perform functionality currently done in the INIT phase.

    Yes, INIT {} functionality is virtually useless if you want to create a generic module and/or a module that should work under mod_perl.

    Liz

    Update:
    Slight rewording of 1st paragraph.

[reply]

      Could you please elaborate on why you can't/shouldn't use INIT with mod_perl? I have never heard of that restriction before, although to be honest, I have never looked either (or ever had a reason too look).

      -stvn
[reply]
        The problem can be easily described with the following code: 
        use warnings;
eval "INIT { 1 }";
__END__
Too late to run INIT block at (eval 1) line 1.

        [download]
        mod_perl basically loads all modules as a string eval. And you can't have INIT code blocks in eval. See also the CGI to mod_perl Porting. mod_perl Coding guidelines.

        I faced a similar dilemma with Thread::Bless: in the end I made sure initializations would only actually initialize once (even if called multiple times), renamed the INIT code block to sub unitialize and added an INIT block that just does a goto &initialize.

        Liz

[reply]
[d/l]
[select]
Re: RFC : Pragma vs. Module
by perrin (Chancellor) on Mar 14, 2004 at 16:56 UTC
    Using a pragma-style name without actually being a pragma is severely frowned on by many people. To make a pragma, you need to convince p5p that your change belongs in the core of perl, and get it added to the standard library and mentioned in the docs. If you don't do all of that, it's just a module, and it should be named appropriately.

    Don't just take my word for it. If you take a look at some of the modules with pragma-style names on CPAN, you will see some pretty harsh reviews.

[reply]
      Using a pragma-style name without actually being a pragma is severely frowned on by many people.
      But what is a pragma? If it's a module that fiddles with $^H, and "pragma-style" names means a name in lowercase, then there are many "violations", including in the Perl core. (constant.pm for instance).

      Abigail

[reply]
      Look at lib.pm. It's a "pragma", but all it's doing is manipulating @INC in a pretty straight-forward way, and it's pure-perl, too.

      Anyway, I just mean that what is meant by "pragma" is open for a certain degree of interpretation. 

      ------------
:Wq
Not an editor command: Wq

      [download]
[reply]
[d/l]
        ...I just mean that what is meant by "pragma" is open for a certain degree of interpretation.

        I agree:

        Mind you, none of these modules are registered, so I'm really avoiding the issue...

        Liz

[reply]
        I don't understand your point. The 'lib' pragma is part of the core library and is listed in perltoc. That's exactly what I was saying needs to happen to create a pragma. I didn't say anything about implementation language.
[reply]
      That's kind of ambiguous. It's not what the module does that would be a problem (though some people would only call a pragma something with lexical scope that has a compile-time effect); it's the use of lower case. Top-level lower case names are reserved for use by perl5-porters.
[reply]
        Yes, the naming is what I was talking about. Sorry if that wasn't clear.
[reply]

      I hear what you are saying, especially regarding naming. It makes sense that the p5p would want to keep that to themselves.

      Personally, I have always thought of pragmas as being "hints" for the compiler, in its simplest definition. (At least that is what pragmas are in Ada95, which is where i first learned about them.) But being that Perl has such a richer interface to its compiler, I suppose I had extended that definition to also include anything that messes around with symbol tables during any of the compiliation phases. Maybe my definition is too broad, as these things would be better thought of as macros/pre-processors rather than pragmas.

      -stvn
[reply]

Back to Meditations