[Mono-list] Missing Types from corlib
Nick Drochak
ndrochak@gol.com
Fri, 4 Jan 2002 23:39:08 +0900
> I see attributes as mainly runtime modifiers: they donīt add
> code to your
> class, but instead to the class-loading process, and are used by some
> sophisticated framework classes to know how to deal with your
> class. Any
> unused attribute penalizes the iteration those classes perform on the
> attribute colections attached to your type, method, property,
> parameter...
These are good points. Perhaps we hadn't considered the possible
performance penalty of adding attributes. Does anyone have a good idea
of what that penalty would be?
My first desire was to get the info from class.xml into the source where
it is easier to maintain. Attributes popped into my mind first.
However, since comments go into the source code too, they work just as
well as attributes in that sense.
From there we want to generate docs (and web pages) that show the
completion status of the class libraries. I suppose we could use XSLT
to generate that from your proposed 'extended doc comments' just as
easily. It might even save us a step, since the diff tool probably
would not generate the docs directly, but some kind of XML. That XML
would then be used to make the docs/web pages.
The only thing left to consider is the advantages of Attributes. They
are transported more easily with the assembly since they're embedded.
Also, they can more easily be used by other tools that may use/examine
an assembly. For instance, my other plan was to extend the Nunit tests
to look for the [MonoTODO]'s and avoid testing incomplete methods, for
example. And an automated build system could run the unit tests after a
commit and email the committer and class maintainer if a test fails.
The maintainer's email address would be in the attribute.
I suppose any other tools that wanted that information could parse the
XML file for it, but it seems easier to do it with attributes.
My 2 cents,
Nick D.