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

[Frank Strauss <strauss@ibr.cs.tu-bs.de>]

Hi!

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

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

I agree. -- But...

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

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

I do not agree.

People cannot do what the protocol does not allow: They cannot use
methods! They have to handle MIB objects or PIB PRIs in a way so that
they achieve what they want to achieve. Today, good MIBs and PIBs have
good DESCRIPTIONs and the containing documents have descriptions of
procedures if they are well written. Formal methods (i.e. the
declaration method signatures) with today's SNMP and COPS-PR would not
help any further. What might help, is the (to some degree formal)
description of procedures (issue #38) within the SMIng modules.

Andrea> 3. Exceptions and methods

Andrea> The original requirements described methods as method
Andrea> signatures - method name, return value, and in/out parameters.
Andrea> This is very mappable into the attributes of MIBs and PIBs,
Andrea> and the constructs of SMNP and COPS.  

I disagree that it would be a good idea to introduce new MIB objects
and PIB PRC attributes to pass parameters and launch agent
functions. This would introduce numbers of ugly side effects requiring
in turn lots of ugly contraints on those `articifial' objects. SNMP
and COPS-PR are simply not made for method invocations.

In my opionion the only win could be on the manager side: Formal
methods could be regarded as (part of) an abstract API. It could ease
the implementation and usage of libraries supporting high-level
operations on a specific MIB/PIB. But again, this is what we called
procedures, not methods.

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


[I stopped adding comments to the requirements list, since our chair
 announced the end of the open discussion and people should have time
 to read the quite voluminous list. If you regard this and future
 threads as relevant for the final discussion on/editing of the
 requirements document, please keep them in your personal folder.]

 -frank