On Fri, Mar 28, 2003 at 11:15:00AM +0100, Johan Vromans wrote: > Technically, this is true. But is this POD? Would you call this C: > > int foo(int bar) { > _asm("..."); > _asm("..."); > _asm("..."); > _asm("..."); > }
Why, of course yes. There are plenty of perl programs nowadays containing nothimg more than a couple declarations and Inline::C blocks, and they are still perl. > The 'danger zone' for Mark's idea is to use POD-like stuctures, which > may people trick into thinking they're dealing with POD while in fact > they're not. If running OODF through a POD processor produces anything > useful, people will think it _is_ POD. Correct. If that is the design goal, then I still think Pod::OO is the better name for it. > Along the same lines, the embedded directives like B<>, I<> are wrong > (or at least dangerous) and should be replaced with more descriptive > directives. Depends on Mark's objective. Again, if he allows these PODesque mark-ups (especially L<>) in OODoc, many people will apply the "if it looks like POD, and it smells like POD..." argument. > If I were Mark, I would leave POD completely and go for something new. > > @FILE Java Call In Implementation | > @IN_MODULE FF > @LOCAL > @FUNC | > @COPYRIGHT > @OWNER > @HISTORY > @PR 0 | 981001 | e03371 | 7.2.04 | wwo | Initial version taken from the > prototype > @COMMENTS > @XREF If Mark goes with this route, then OODF or OODOC or MarkDoc are equally applicable, since it's something that has no relation with Pod, and (to borrow Mark's C => C++ metaphor) warrants a completely different name like "Java" did. So the question is... What does Mark wishes to achieve: syntactical compatibility, or radical departure? Thanks, /Autrijus/
pgp00000.pgp
Description: PGP signature