[gmt-dev] Overloading and inheritance (was UMLX pages and new UMLX paper

["Willink, Ed" <Ed.Willink@xxxxxxxxxxxxxxx>]

Hi All

I Wrote
> 
> One that struck me this morning is transformation overloading. At the
> moment invocation of a family of polymorphic transforms requires them
> to be named distinctly and invoked from a dispatcher that enumerates
> all known names.
> 
> It is of course perfectly reasonable to allow same-signature 
> transforms to be
> chosen by unambiguous LHS match. This should save at least 
> one transform in
> the example, and open the way to extensibility. (Signature is 
> transformation
> name and port names, which may be annotated as optional/defaulted).
> 
...
> 
> Exceptions and Error reporting are still TBD. I sorted out
> overloading above. I thought I was beginning to know what inheritance
> means - but overloading seems to nullify my current thoughts.

The above doesn't work.

Overloading allows a typically static choice between a number of
alternatives. The set of alternatives is typically defined within a
specific nameapace making encapsulated extension difficult,
hence operator<< in C++ must be in the unnamed namespace.

Matching involves application of all alternatives, so the above ideas
fail to support extensibility and are inconsistent by selecting an
unambiguous match rather than all matches.

Inheritance supports alterative or extended behaviour.

It therefore seems that the useful way to support transform
extensibility is via transform inheritance. An invocation of the base
transform activates all derived concrete implementations, which
may be arbitrarily named, but must share the base interface.

Orthogonal extensibility is therefore supported by just adding
compatible derivations. 

Transformations may be abstract in order to define a signature and
possibly a shareable implementation, without participating in the set
of 'all' derived concrete implementations. I suspect that any
transformation from which another derives must automatically be abstract,
since matching of both base and derived transformation is unlikely to
be useful; if the base transformation has useful functionality, the
derived transformations must rescue it.

It may be sufficient to interpret UML 2 package merge concepts for
transformations as meaning rewriting to support refinement. A duplicate
transformation name in a package extension must match the interface
that it replaces. Within the extension the replaced transformation
may be invoked explicitly so that the replacement can act as a wrapper.
Overloading is therefore only meaningful in the context of refining
a transformation, overloading cannot create a competing transformation.

Support for transform inheritance and package inclusion requires a
proper Package Diagram within GME/UMLX. This is easily achieved by
changing the current Folder hierarchy to a Package Diagram hierarhy
- indeed this is almost the structure I had at one point.

I will probably put the graphics support for this in soon, so that
at least the diagrams can be drawn. Implementation is not a high priority.

	Regards
			
		Ed Willink

------------------------------------------------------------------------
E.D.Willink,                             Email: mailto:EdWillink@xxxxxxx
Thales Research and Technology (UK) Ltd, Tel:  +44 118 923 8278 (direct)
Worton Drive,                            or  +44 118 986 8601 (ext 8278)
Worton Grange Business Park,             Fax:  +44 118 923 8399
Reading,   RG2 0SB
ENGLAND          http://www.computing.surrey.ac.uk/personal/pg/E.Willink
------------------------------------------------------------------------
(formerly Racal Research and Thomson-CSF)

As the originator, I grant the addressee permission to divulge
this email and any files transmitted with it to relevant third parties.