Paul,

>
> there were also ideas that fall in between:
>
> [http://archive.develooper.com/p5ee%40perl.org/msg00472.html]
>

I read this message (maybe the attribute example I given in my message looks
familar too you :-), but I don't see where the two ideas below shows up
there (but of course it is possible, that I don't have the whole thread
correctly in mind), so let look:

> 3. have something that looks like Attribute::*, but is parseable by
> extended POD utility
>

Either it is a attribute that is recognized by Perl, then it won't work with
Perl 5.005 or it isn't and then I don't see what you gain here.

> 4. have something that looks like POD, but is parseable in
> compile/run-time:
>
> use constant POD => <<EOPOD;
>

I think this generates too much runtime overhead (for the normal case, where
the metainformation is not needed). There is no reason why we can't parse
the whole source file at runtime instead of make time. It would be possible
to check the timestamp of the meta file and the source file and start the
parser as necessary, but I am really not sure if this would be a big
advantage, because every module should be installed by "make install" and
this makes sure that the source and the meta information is up to date. Of
course somebody would be able to change the source directly inside the perl
libs dirs, but this is really not a clean way of doing things.

>...
> This code IS pure POD and doesn't require any modification in POD
> processing.
>

As soon as we want have information automaticly retrived, we need something
more than pod

> It might be possible to create Attribute::* method that will accept
> that code and generate structure it needs.
>

That could be done with my comment solution as well

> Ideally I see it as two-way road: I should be able to generate that
> POD fragment from Attribute::* code.

Of course there is no reason, for people who prefer that way,  to generate
the comments from attributes.

BTW. My suggestion can of course also occur inside POD or any other text
files. There would be some formatter that creates normal pod from the
comments/extented pod when make runs.

Gerald


-------------------------------------------------------------
Gerald Richter    ecos electronic communication services gmbh
Internetconnect * Webserver/-design/-datenbanken * Consulting

Post:       Tulpenstrasse 5         D-55276 Dienheim b. Mainz
E-Mail:     [EMAIL PROTECTED]         Voice:    +49 6133 925131
WWW:        http://www.ecos.de      Fax:      +49 6133 925152
-------------------------------------------------------------



Reply via email to