On Sun, Sep 02, 2001 at 09:11:09AM +0100, Graham Barr wrote:
> > We already have an 'other'. ' n - no interface at all (huh?)'.
> > Module authors are using it to mean 'other'.
>
> Then use n for your module.
If 'n' is going to officially be 'other' then please change the
description.
> > Text::Template Simply describing these with O or f doesn't do
> > Embperl justice to the fact that the *real* point is
> > HTML::Mason the ability to embed code into other mediums.
> > Test::Inline
> > Inline::C
>
> Again, you are describing what the modules does, not how the
> programmer would use it. Text::Template is most definately an OO
> interface.
<snip>
Ok, lemme try and 'splain better.
What is the -->*use to the users of CPAN*<-- to describe
Text::Template, or Inline::C as having an OO or procedural interface?
If I'm looking at the description of a module...
Text
::Template MdpO? Expand template text with embedded perl MJD
I see this information:
- called Text::Template
- the code is mature
- suppored only by the developer.
- written in pure perl.
- it has an OO interface
- license is not officially mentioned
- short description
- the author.
All those pieces of information are in some way useful to know
at-a-glance before deciding to download and investigate the module
further EXCEPT the fact that it's OO.
Written with an OO interface... now how does that effect my decision?
Would I reject the module if it were procedural? Does it make it
harder/easier to use the module with my program? Is an OO module
easier to use in an OO program? Is an OO module harder to use in a
procedural program or vice/versa?
Is this: foo($data, @args) really different than this $data->foo(@args);
to the user of the module?
Do I need to learn object-oriented programming to use the mdoule?
(A common misconception.)
What's the difference? Text::Template tells me it has an OO API.
That's true, but why is this useful? How does this effect my decision
to download the module?
It's about as useful as knowing it uses StudlyCapsStyle vs unix_style
names.
So rather than wasting the API slot with technically true-but-trivial
information, why not alter it so it can provide some *useful*
information about the purpose of the module?
--
Michael G. Schwern <[EMAIL PROTECTED]> http://www.pobox.com/~schwern/
Perl6 Quality Assurance <[EMAIL PROTECTED]> Kwalitee Is Job One
HA HA HA You're all so ridiculous! But thanks for the money!
