> On Sun, Feb 03, 2002 at 10:58:00AM -0500, Jay Lawrence wrote: > > : > > 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...
Yeh - and actually if I'm not mistaken your module really does all the work of sorting out what's going on in the symbol table. Really it is coming down to improved documentation of module properties and methods such that they can be reused in a visual development or configuration enviornment. I have a vision much like what our favourite GUI offers for configuring that favorite widget's properties. I'm thinking brief description of the property. Some notation of the types of input the property or method wants to see (prototypes + a bit more detail?). Mentioning what kinds of output the thing will produce? > The POD method trips on problems #1 and #3 below: I'd hope that POD is written in such a way that other developers are gonna understand said module's properties, functions and methods. If the author does not write POD I'd probably eliminate as a candidate component anyway. But still I hear your points. :) Anyway, I am trying to avoid hubris, wheel reinvention or re-engineering, toe stepping, or any other sorta turf invasion before venturing into proposing my own strategies. :) I shall continue to ponder having now added your 4 points you have so kindly given to me - and have been taken to heart. Cheers, J > 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 >
