Hi Fred,
I must say this "do what you want" expression is getting to sound a little
unpleasant ;-)
We will all do what we want, of course. But we are also in this group to help
and be helped.
Part of the idea of FuseDocs and my inline comments is that you have special
comments can be identified by a parser and used in automated documentation,
validation, etc.
In this sense, yes, there are some comments that you don't particularly want
to see in the extracted documentation (eg, initialize temporary variable for
accumulating string). Furthermore, tagging your comments with a CommentType
allows them to be grouped apropriately for display. My original idea was that
this would allow inline comments to be re-assembled into something like Hal's
FuseStub, but this is obviously unnecessary if FuseStubs are included
explicitly.
My current intention is to go with Hal's Fuse-stubs, but to also parse
specially marked inline comments into the same structure, so that the choice
remains with the developer about how they want to do these things. As has
been noted here often enough, we are not in the business of imposing our
methods on others.
To summarize, there will be three types of comment:
1: FuseDoc fuse-stub;
2: Specially-marked inline comments (semantically equivalent to the FuseDoc
fuse-stub comments;
3: Standard inline comments, ignored by parser and auto-documentation
routines.
This way, the choice is the developer's (or the organization's). Use Hal's
fuse-stubs, or equivalent inline comments, or both, or none. will write a
single parser and a single display module to handle all of these options.
The result should be that we get the same auto-documentation, independent of
the low-level comment syntax chosen by the developer.
All I'm aiming at, Fred, is a solution that's flexible enough for most
everyone, without descending to anything-goes confusion. I know you hate the
idea of standards, so I'm just offering to distribute the tools I have made on
the off chance that someone else might find them useful. As for myself, I
will now be using FuseDoc fuse-stubs with the odd inline comment where
appropriate.
Thanks all,
Lee Bjork Borkman
Bjork.Net - ColdFusion Tags by Bjork
"Fred T. Sanders" <[EMAIL PROTECTED]> wrote:
I'm having a little trouble understanding why you need to make the inline
comment with an additional @ added.
If your only doing it so that you can define which comments to pull and
which not to, then I think maybe you should
re-evaluate what your commenting and why the block of code is commented in
the first place. There shouldn't be
useful and non-useful comments. They should either be useful comments or
they shouldn't be there.
My 2 cents, do what you want.
Fred T. Sanders
Charlottesville, VA
____________________________________________________________________
Get free email and a permanent address at http://www.netaddress.com/?N=1
------------------------------------------------------------------------------
To Unsubscribe visit
http://www.houseoffusion.com/index.cfm?sidebarRsts&bodyRsts/fusebox or send a message
to [EMAIL PROTECTED] with 'unsubscribe' in the body.
