On Sun, Feb 03, 2002 at 10:58:00AM -0500, Jay Lawrence wrote:
> Hi Michael,
>
> I just had a quick look at your module - looks cool! I'll give this a whirl
> sometime soon.
>
> On a tangential note - something I've been bringing up here 'n there is the
> notion that it would be really interesting if classes would supply this and
> more class/module-related info. In other words - runtime documentation.
> Method to return list of properties or methods in a class. Method to return
> detailed information about a property. We do this and we can make the
> creation of much more interesting run-time environments easier.
That information is already easily available at run-time, just look at
the class's symbol table. Trick is, you can't tell the difference
between a public and private method unless they've followed the
public()/_private() convention, which you probably already know...
> Really its just a case if a module wishes to offer run-time documentation
> they would have a few well known methods/functions. The issue is deciding
> and making those functions well known. :) I've mentioned this briefly on the
> POOP list and I see that P2EE might be related (but they've got bigger
> things on the - go I fear). I've thought about maybe tying this to the
> module's POD by looking to to a POD filter thus saving duplication of
> effort - but maybe introducting some influence on how methods, etc. are
> documented in POD.
The POD method trips on problems #1 and #3 below:
> Is ths something that you or others think about or ponder?
The four [1], rather huge, problems with coming up with some sort of
sensible scheme are:
1) How to let a class author specify the information without being
blatantly redundant with the code:
2) How to do it without causing much extra compile-time overhead.
3) How do you get people to use it?
4) How do you get people to use *just one*?
#3 and #4 being by far the hardest, this being Perl and all.
A POD-based solution trips up because its always going to be redundant
with the code (ie. #1).
P2EE seems to have trouble with all four, but I think #3 and #4 will
likely give it the most indigestion. Its trying to do so much more
than just introspection, and many CPAN authors (myself included)
aren't thinking about "Enterprise" [2] contexts when writing a module.
Problem is, lots of Enterprise systems want to use CPAN modules. So
how do you convince CPAN authors to jump through the extra hoops to
use P2EE if it doesn't benefit them? [3]
[1] I started with two. AMONGST the huge problems...
[2] Which is an awful show anyway.
[3] Because CPAN is 1% altruism, 99% hubris, to paraphrase TEDISON.
--
Michael G. Schwern <[EMAIL PROTECTED]> http://www.pobox.com/~schwern/
Perl Quality Assurance <[EMAIL PROTECTED]> Kwalitee Is Job One
Maybe they hooked you up with one of those ass-making magazines.
-- brian d. foy as misheard by Michael G Schwern
