- About Scala
- Documentation
- Code Examples
- Software
- Scala Developers
When will future scaladoc abilities be implemented?
Sat, 2010-10-23, 20:08
I know there are plans for future scaladoc abilities to be implemented, such as bulleted lists and so forth. I was wondering if there is a timeline for this?
Also, could I ask you to consider scaladocs carefully and as part as the overall language, rather than as an afterthought? As a tech writer, I see far too much consideration of tech writing as "after the fact" work. The really important part is the programming, the tech writing is subsidiary.
This is fundamentally wrong because the engineers using your code rely on the tech writing to use it effectively. Yes, if all else fails, they can drop down into the code base and analyse the code from there. But just how much time does that cost?
The most concrete example I can give is that of having parameter comments "inline" with the parameter declarations. While there were a number of options of how to achieve this, the broad consensus (I think) was that it was a worthwhile idea. It makes it much less likely that parameter comments will be omitted, and much more likely that they will be kept up to date. It also makes the comment parsing process easier. There are probably other advantages.
So please, scala team, as you define scaladocs, think about what is necessary to make them work on large scale projects, not just as an adjunct to the programming process.
Thanks,
Ken
I agree that "inline" comments are preferable. However, I don't see why we can't please everyone here. If a significant number of people want to maintain the javadoc style, then keep it. However, if a javadoc-style comment is not found for a particular method, then have scaladoc look for inline comments. As I've said before, I think inline comments should look like regular comments, as in
def foo(
arg1: Int, // this is the first argument
arg2: String, // this is the second argument
arg3: Bar /* this is the third argument. This is a long
comment with a line break. */
): Int = {
/* This method is called foo. If you need to know more, sorry but I have more
important things to worry about. You got a problem with that? */
...
}
I would also make it recognize a comment immediately after the def, as in
def foo( // this method is not called bar
Russ P.
--
http://RussP.us