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


/ "Fred L. Drake, Jr." <fdrake@acm.org> was heard to say:
| Norman Walsh writes:
|  > Is the following observation correct: there's no dispute about
|  > the semantics for exceptions or interfaces, the only point of
|  > contention in the current proposal is whether or not
|  > superclasses need to be called out in some more explicit way
|  > than order among siblings.
| 
|   I think that's roughly right, though your asking and our discussion
| to this point makes me think that the set of superclasses / interfaces 
| should be separate from the set of allowed exceptions.  This is mostly 
| a result of wanting to allow "exceptions" which are distinct from
| "classes" (which *is* the case for Modula-3, but there is no concept
| of exception inheritance: exceptions cannot be derived from other
| exceptions) [note: I'm not actually aware of any language which
| distinguishes exceptions from classes *and* supports exception
| inheritance].

Gosh, considering I wrote support for opaque types in (what was
then going to be) the GNU M3 compiler, you'd think I'd be able
to follow what you're saying, but I can't. It's been, um, a while :-).

It seems to me that the use of <classname>, <interfacename>, and
<exceptionname> adequately separates the set of
superclasses/interfaces from the set of allowed exceptions...

Can you show me some examples that illustrate what you're
getting at. I'd love to see some complex M3 interfaces that you
think would be problematic to document with the current
proposal.

|   If DocBook is to support such languages, there needs to be a marked
| separation between what something is (superclasses & "implements"),
| and what exceptions can be raised by constructors.  That might be the
| way out:  the class itself doesn't raise exceptions, only it's
| methods.

The model already allows you to specify what exceptions a method
or constructor raises, but some languages require that you
enumerate them on the class as well (e.g., Java).

                                        Cheers,
                                          norm

-- 
Norman Walsh <ndw@nwalsh.com>      | Graduate school is where you learn
http://www.oasis-open.org/docbook/ | to call a spade a leveraged
Member, DocBook Editorial Board    | tactile-feedback geomass delivery
                                   | system.--Martha Koester



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Powered by eList eXpress LLC