Re: long method signatures in uml class diagrams

["James K. Lowden" <jklowden schemamania org>]

On 13 Oct 2002 14:35:51 -0500, Lars Clausen <lrclause cs uiuc edu> wrote:
> > Would you say the following is an
> > example of "an overly complex system"?
> >
> > template <class charT, class traits, class Alloc>
> > basic_string<charT, traits, Alloc>
> > operator+(const basic_string<charT, traits, Alloc>& s1, charT c)
>
> Yes, I would, but that's really a gripe about C++, not about his system.
> The fact that you need to specify three templates for basic strings is
> vile beyond belief, IMNSHO.  [...]

Hmm.  I can agree with the NSH part, sure.  ;)  

The charT argument provides for strings of different datatypes, nicely
addressing Unicode, for instance (OS limitations notwithstanding).  The
optional Alloc allows the user to define his own allocation scheme, a
help.  You could accomplish these things without templates, but you'd only
wind up moving the complexity somewhere else.  And the typical case,
string, has the advantage of being both easy to declare and having access
to basic_string's generalized machinery.  

Complex, perhaps.  But "overly" to me means "avoidable".  I don't think
you can remove anything from that declaration without removing
functionality, too.  

But this isn't a C++ newsgroup.  I reply only because I think you're
underestimating the goodness of long signatures that the UML object may be
asked to hold.  

> We obviously don't want to blindly insert linebreaks everywhere we can,
> as then the objects would just be too tall rather than too wide.  I
> could probably cook up a little pretty-printer that has some idea about
> when it'd be good to break lines.

If somebody wants to use the UML class this way, he's going to need a long
and short form IMO.  Maybe the user could provide a "display string" to
override the complete representation of a function.  If the UML class
actually understood C++, it would have enough information to offer
gradations of detail, choosing among:

        Class name
        Class template parameters
        Data member names
        Data member types
        Function names
        Function template parameters
        Function parameter types
        Function parameter names
        Function return types

I realize this is empty noodling, but the UML class is such a "hairball"
(quoting Cyrille) and in such need of extension in several directions,
that it's bound to be replaced one of these days, when someone gets
ambitious.  

Slay any dragons yesterday?  Rescue any damsels?  (No and yes,
respectively, I hope.)

Regards, 

--jkl