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

["Andrea Westerinen" <andreaw@cisco.com>]

Some text and replies pulled up here:

1. David's comment and Juergen's reply are based on the following
assumption - that you can define a class with "a method with a return value
of one type, but my newly defined class has a method of the same name but
returns another type".

Why do we have to/want to allow this?  In SNMP today, if you define some
"standard" MIB and object attributes, you should not redefine those
attributes as different types - but as new "non-standard" attributes.  This
is not an argument against methods, but an argument against redefining
attribute types and method signatures.

2. Juergen says "We are not supposed to create a generic (information)
modelling language."

But, we are supposed to create a language that reduces the number of errors
and clarifies semantics.  Joel stated the counter-argument here very well
when he said "people are already
doing those ugly things by hand, without the clarity that comes from
explicit method descriptions.  Continuing to use a kludge because that is
what people have done does not seem a good answer when we can do
significantly better."

3. Exceptions and methods

The original requirements described methods as method signatures - method
name, return value, and in/out parameters.  This is very mappable into the
attributes of MIBs and PIBs, and the constructs of SMNP and COPS.  The idea
of exceptions was added afterwards (I think by Juergen, but I may be wrong).
I agree that they are two separate things.  The try...catch approach would
be very difficult to support.  However, the approach of sending an exception
as a standard notification/event is doable.

Andrea

-----Original Message-----
From: owner-sming@ops.ietf.org [mailto:owner-sming@ops.ietf.org]On
Behalf Of Juergen Schoenwaelder
Sent: Wednesday, May 02, 2001 1:43 AM
To: david.putzolu@intel.com
Cc: sming@ops.ietf.org
Subject: Methods, Inheritance, Exceptions, etc. (was: Re: Methods in
SMIng ?)



>>>>> 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/>