OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

docbook message

[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