Bug 648 – DDoc: unable to document mixin statement
Status
RESOLVED
Resolution
FIXED
Severity
normal
Priority
P2
Component
dmd
Product
D
Version
D2
Platform
All
OS
All
Creation time
2006-12-04T03:32:00Z
Last change time
2014-03-12T13:59:49Z
Keywords
ddoc, pull
Assigned to
andrej.mitrovich
Creator
tomas
Comments
Comment #0 by tomas — 2006-12-04T03:32:41Z
/// this is a class
class A
{
/// This mixin will bla bla bla
mixin MyMixin!();
}
this will only generate docs for the class. not the mixin.
Some will probably consider this a feature request, but I'd call it a bug...
Comment #1 by gobstocker — 2007-05-06T23:12:25Z
(In reply to comment #0)
> /// this is a class
> class A
> {
> /// This mixin will bla bla bla
> mixin MyMixin!();
> }
>
> this will only generate docs for the class. not the mixin.
> Some will probably consider this a feature request, but I'd call it a bug...
>
The same occurs with mixin declarations (DMD 1.014 on linux):
/// Documentation for foo.
mixin("int foo;");
mixin("int foo; /// Documentation for foo.");
And docs are not generated for foo or bar.
Gregor Richards pointed out in
news://news.digitalmars.com:119/[email protected]
that mixins are parsed much later than ddoc comments.
But I would also consider this a bug.
Comment #2 by jdrewsen — 2012-01-21T11:50:17Z
(In reply to comment #1)
> (In reply to comment #0)
> > /// this is a class
> > class A
> > {
> > /// This mixin will bla bla bla
> > mixin MyMixin!();
> > }
> >
> > this will only generate docs for the class. not the mixin.
> > Some will probably consider this a feature request, but I'd call it a bug...
> >
>
> The same occurs with mixin declarations (DMD 1.014 on linux):
>
> /// Documentation for foo.
> mixin("int foo;");
>
> mixin("int foo; /// Documentation for foo.");
>
> And docs are not generated for foo or bar.
>
> Gregor Richards pointed out in
> news://news.digitalmars.com:119/[email protected]
> that mixins are parsed much later than ddoc comments.
>
> But I would also consider this a bug.
Comment 1 is a duplicate of bug 2420
(In reply to comment #0)
> /// this is a class
> class A
> {
> /// This mixin will bla bla bla
> mixin MyMixin!();
> }
>
> this will only generate docs for the class. not the mixin.
> Some will probably consider this a feature request, but I'd call it a bug...
I would call it a feature request, because for it to be a bug, there would have to be a clear definition how this should work or a similar case that can act as a template. DDoc documents 'classes', 'structs', 'methods', ... in other words named symbols. "mixin MyMixin;" isn't a symbol and usually not interesting for the user of the class. And private members aren't documented, because they aren't usable by the target audience of API docs. So I assume your mixin does not itself add public symbols that should be documented ? Or do you request a feature to go beyond API documentation with DDOC, and also document how a mixin is expanded in the class ? That's what normal comments are for!
Maybe you can elaborate a bit on what the mixin does and why it is necessary to document the 'unexpanded' thing ? I would say yes, if you proposed to move DDOC generation after mixin expansion (so newly introduced methods can be documented), but then you could document them inside the mixin itself - which would be a different 'bug'. Remember that a single mixin can add any number of new symbols, so documentation above "mixin ..." may come short in many situations. You can also discuss this on the D newsgroup, but be sure to give a strong argument (real example code) for this feature.
Comment #6 by tomas — 2012-01-27T05:45:44Z
It's been five years. TBH I don't really care anymore. Close this issue up if you will, I've moved on ...
(In reply to comment #5)
> (In reply to comment #0)
> > /// this is a class
> > class A
> > {
> > /// This mixin will bla bla bla
> > mixin MyMixin!();
> > }
> >
> > this will only generate docs for the class. not the mixin.
> > Some will probably consider this a feature request, but I'd call it a bug...
>
> I would call it a feature request, because for it to be a bug, there would have
> to be a clear definition how this should work or a similar case that can act as
> a template. DDoc documents 'classes', 'structs', 'methods', ... in other words
> named symbols. "mixin MyMixin;" isn't a symbol and usually not interesting for
> the user of the class. And private members aren't documented, because they
> aren't usable by the target audience of API docs. So I assume your mixin does
> not itself add public symbols that should be documented ? Or do you request a
> feature to go beyond API documentation with DDOC, and also document how a mixin
> is expanded in the class ? That's what normal comments are for!
>
> Maybe you can elaborate a bit on what the mixin does and why it is necessary to
> document the 'unexpanded' thing ? I would say yes, if you proposed to move DDOC
> generation after mixin expansion (so newly introduced methods can be
> documented), but then you could document them inside the mixin itself - which
> would be a different 'bug'. Remember that a single mixin can add any number of
> new symbols, so documentation above "mixin ..." may come short in many
> situations. You can also discuss this on the D newsgroup, but be sure to give a
> strong argument (real example code) for this feature.
Comment #7 by raphael.londeix — 2012-03-17T11:08:55Z
Hi,
I would say that document mixins themselves is not really useful (like Marco
Leise said, the targeted audience of the generated documentation). However,
since the compiler generates documentation (which is an awesome fact btw),
it could also generate doc for generated source code from mixins.
When the generated code goes on a public scope, having it documented is not
only useful, it is necessary. For example, I use mixin to generate some
callbacks accordingly of a network protocol definition. Since the protocol
is known at compile time (and fully documented), these callbacks should be
documented as well.
Feature or bug, I don't know, but it's not working with dmd v2.058 :)
Comment #8 by andrej.mitrovich — 2013-01-13T12:50:59Z
The string mixin issue isn't fixed, but that is issue 2420.
Comment #12 by andrej.mitrovich — 2013-01-14T13:47:36Z
It's not fixed.
The revert should have been done in full because of the uncaught bug, instead you created your own fixup of my pull and now master is failing: http://d.puremagic.com/test-results/
You should revert everything and allow me to work on the fix again.
Comment #13 by bugzilla — 2013-01-14T14:09:56Z
reverted.
Comment #14 by doob — 2013-01-14T23:27:29Z
I think this would be useful to have. For example:
/// doc
class Foo
{
/// doc
mixin Singleton;
}
In this case you might want that the singleton should be documented and part of the public API. It would be a good idea to know that Foo is a singleton.
Another example:
/// doc
class Bar
{
/// doc
mixin Property!(int, "x");
}
The mixin would expand to something like:
private int x_;
@property int x () { return x_; }
@property int x (int value) { return x_ = value; }
Comment #15 by andrej.mitrovich — 2013-01-20T10:56:05Z
Any progress on this? This is a real show-stopped for my std.logger.
Comment #17 by andrej.mitrovich — 2014-02-16T08:40:16Z
(In reply to comment #16)
> Any progress on this? This is a real show-stopped for my std.logger.
The pull is up to date, and almost ready to be merged.
Comment #18 by rburners — 2014-02-16T11:55:30Z
(In reply to comment #17)
> (In reply to comment #16)
> > Any progress on this? This is a real show-stopped for my std.logger.
>
> The pull is up to date, and almost ready to be merged.
awesome. this is blocking my std.logger development. thank you
Comment #19 by github-bugzilla — 2014-03-12T13:25:07Z