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

["Putzolu, David" <david.putzolu@intel.com>]

Juergen> The WG charter says that we do a "next generation data definition
Juergen> language for specifying network management data". We are not
supposed
Juergen> to create a generic (information) modelling language....

I agree with this - thus my argument for reducing the requirement set.


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

I think inheritance adds substantially more complexity when one is
supporting methods.  At the minimum, one needs to define a way to
indicate which functions in an inheritance hierarchy take precedence -
C++ uses the virtual keyword, Java uses the final keyword.  There are
also issues around how one refers to or invokes superclass/parent functions.

I believe that handling inheritance when dealing with attribute collections
is enough work, and support for methods in the base specification is
more complexity and work.

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

I'm not sure I understand here - it seems to me that if we allow
both inheritance and methods, then we have to explain how they
interact.  Maybe an example would help - lets say I use SMIng
to define a class called MyClass that exposes a method called
Foo.  Now lets say someone else defines TheirClass, which derives from
MyClass, and also exposes Foo - with an identical signature (and name),
but different semantics.  Given this scenario, how would it translate to 
GETs and SETs across the wire?  Looking for specific examples of how to
do this mapping, because from what I can see so far, no clean mapping
would be possible.


Juergen> A good example are the INSTALL-ERRORS in
Juergen> the SPPI which enumerate the exceptions that can happen while
creating
Juergen> a new row via COPS-PR. Note that this notion of exceptions is
Juergen> completely independent from the way an application written in a
Juergen> particular programming language processes exceptions. The
try...catch
Juergen> block is a programming language construct and we are of course not
Juergen> going to specify this.
Juergen> If you want an example how this can work, then please take a look
at
Juergen> the CORBA world. 

I'm familiar with the Java and CORBA models - I used C++ in my
example just to pick a well known starting point to illustrate that
exceptions typically have a fairly rich semantic associate with them.  
In particular, one thing common to C++, CORBA, and Java exceptions is
that their exceptions follow a different flow of control than just 
returning an error value.  It is this behavior that makes the 
appearance of exceptions in the context of SMIng alarming to me.

That Juergen mentions INSTALL-ERRORS is perhaps illuminating - my reading 
of SPPI is that INSTALL-ERRORS are a way to indicate that a 
provisioning class failed to install successfully.  INSTALL-ERRORS make 
sense, and are a special kind of error - is that what is meant with
the word exceptions?  If what is being advocated is simply some 
special types of predefined error codes or types that can be returned
to signify exceptional *conditions*, that may be ok - but then we should
not call it exceptions - rename it. Just as classes may need to be renamed
attribute groupings, maybe exceptions should be called something else.


Andrea> The idea of exceptions was added afterwards (I think by Juergen, but
I may 
Andrea> be wrong). I agree that they are two separate things.  The
try...catch approach would
Andrea> be very difficult to support.  However, the approach of sending an
exception
Andrea> as a standard notification/event is doable.

I believe exceptions should definitely be considered as separate items
from methods.  WRT notifications/events - in programming languages
exceptions 
are synchronous responses to method invocations (in CORBA they can also
be raised in response to attribute manipulations).  My interpretation
of events/notifications is an occurrence of some sort that
is asynchronously signalled from the controlled entity to the controller 
(substitute managed for controlled, manager for controller if desired) - 
e.g., a SNMP TRAP.  TRAPs and error responses to SETs are quite different,
so
I'd like to better understand what is being advocated here with exceptions.

Cheers,
David