[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: Re: DOCBOOK: DocBook 4.0: ClassSynopsis
Norman Walsh wrote: > / Dmitry Tsitelov <cit@comcon.spb.ru> was heard to say: > | > In real life, the attlists will also include local extension > | > parameter entities and role attributes. > | > > | > <!ELEMENT ClassSynopsis - - (Modifier*, > | > (ClassName|InterfaceName|ExceptionName)+, > | > (ClassSynopsisInfo > | > |FieldSynopsis|%method.synop.class;)*)> > | > > | > | . . . > | > | Excuse me for possible misunderstanding, but how this model allow to specify > | such attributes of inheritance, as virtual /public/private inheritance in > | C++ ? I'm sure, there are such attributes in other languages too. > > Those are all "modifiers" in this model (remember, we're documenting not > modelling): > > <classsynopsis> > <modifier>public</modifier> > <classname>foo</classname> > > <methodsynopsis> > <modifier>virtual</modifier> > <type>someType</type> > <methodname>bar</methodname> > <void/> > </methodsynopsis> > </classsynopsis> > > The question of inheritance is still on the table. I think that > for the purposes of documentation, a simple list of class names > and the semantic that the class names after the first are > superclasses is sufficient, but a number of people disagree. > > I'm reluctant to add a lot of structure here mostly because I > don't want the resulting structure to be biased towards a > particular programming language if that can be avoided. I also > don't want to give the impression that it is a goal that you > should be able to generate code from these synopses or > something. > Excuse me again, but how must be documented C++ classes like this one: class Rectangle_with_data: virtual Shape, virtual Data_container { ... }; "virtual" keywords are very important in this situation for class behavior understanding. May be, such modification of ClassSynopsis will be more acceptable: <!ELEMENT ClassSynopsis - - ( ( Modifier*, (ClassName|InterfaceName|ExceptionName) )+, (ClassSynopsisInfo |FieldSynopsis|%method.synop.class;)*)> This variant allows to specify modifiers for each class/inheritance/exception-name, not only for first. I thin it is not very complex, and language independed. Sincerely, /Cit
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC