Methods, Inheritance, Exceptions, etc. (was: Re: Methods in SMIng ?)

[Juergen Schoenwaelder <schoenw@ibr.cs.tu-bs.de>]

>>>>> Putzolu, David <david.putzolu@intel.com> writes:

David> #37: If I define a class (attribute grouping?) that derives
David> from an abstract class, and the abstract class defines a method
David> with a return value of one type, but my newly defined class has
David> a method of the same name but returns another type, which one
David> is invoked?  Questions like this worry me - but I can probably
David> answer this question if the language being used is C++ or Java.
David> However, the goal is not to do all the things that C++ or Java
David> does (come up with a programming language) - it is to make a
David> modelling language.  As such, on requirement #37 I strongly
David> agree with Juergen when he wrote, "I prefer to stay away from
David> methods at this point in time (but make the language extensible
David> so they might be added later)."

The WG charter says that we do a "next generation data definition
language for specifying network management data". We are not supposed
to create a generic (information) modelling language.  My argument for
postponing methods is based on the observation that SNMP as well as
COPS currently do not support method invocation natively and so you
either have a feature in the data definition language which you can't
use in practice (at least with SNMP and COPS-PR) or you have to do
really ugly things to emulate generic method calls on top of what SNMP
and COPS provides you.

The issue of naming scopes and how you resolve conflicts is
important. But I do not think it is very complex to handle this nor do
I think that specifying how you solve name conflicts makes the data
definition language a programming language. We already have rules in
the SMIv2/SPPI how to resolve conflicts if you have to import
definitions with similar names. If we have methods, we sure need more
rules - but nothing conceptually very different.

David> #37, revisited: If we were to do methods, that of course leads
David> to the idea of exceptions.  Exceptions are a great tool for
David> writing high quality software for a number of reasons - but I
David> have no clue how they relate to the case of a data modelling
David> language that will be mapped to on-the-wire SNMP and COPS PDUs.
David> How would I map a try..catch block or a throw() to a SNMP PDU?
David> What meaning does the idea of passing an unhandled exception on
David> to a higher execution context (stack unrolling) have to a
David> DECision message?  I strongly suggest that if methods are done
David> that exceptions not be done.  If methods are not done, the
David> question of exceptions becomes moot.

Exceptions model exceptional conditions that can happen on the "agent"
while you invoke a "method". A good example are the INSTALL-ERRORS in
the SPPI which enumerate the exceptions that can happen while creating
a new row via COPS-PR. Note that this notion of exceptions is
completely independent from the way an application written in a
particular programming language processes exceptions. The try...catch
block is a programming language construct and we are of course not
going to specify this.

If you want an example how this can work, then please take a look at
the CORBA world. The CORBA folks define exceptions at the IDL
level. The programming language binding later says how things are
mapped to programming language constructs. And the mappings look very
different, depending on whether you use C or Java.

/js

-- 
Juergen Schoenwaelder      Technical University Braunschweig
<schoenw@ibr.cs.tu-bs.de>  Dept. Operating Systems & Computer Networks
Phone: +49 531 391 3289    Bueltenweg 74/75, 38106 Braunschweig, Germany
Fax:   +49 531 391 5936    <URL:http://www.ibr.cs.tu-bs.de/~schoenw/>