FW: BOUNCE sming@ops.ietf.org: Non-member submission from ["Putzolu, David"]

["Durham, David" <david.durham@intel.com>]

Forwarding this to the list. Apparently some subscription problem.
-Dave

-----Original Message-----
From: Randy Bush [mailto:randy@psg.com]
Sent: Tuesday, May 01, 2001 1:24 AM
To: Putzolu, David
Subject: BOUNCE sming@ops.ietf.org: Non-member submission from
["Putzolu, David" <david.putzolu@intel.com>] 


you must post from your subscription address

randy


------- start of forwarded message -------
From: owner-sming@ops.ietf.org
To: sming-approval@psg.com
Subject: BOUNCE sming@ops.ietf.org:    Non-member submission from ["Putzolu,
David" <david.putzolu@intel.com>]   
Date: Mon, 30 Apr 2001 12:47:26 -0700

>From david.putzolu@intel.com Mon Apr 30 12:47:25 2001
Message-ID: <638EC1B28663D211AC3E00A0C96B78A8065A4FA5@orsmsx40.jf.intel.com>
From: "Putzolu, David" <david.putzolu@intel.com>
To: "'sming@ops.ietf.org'" <sming@ops.ietf.org>
Subject: Methods, Inheritance, Exceptions, etc. (was: Re: Methods in SMIng
	?)
Date: Mon, 30 Apr 2001 12:47:17 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"

I've gone through the requirements page (btw, great job Frank).
Individually, a lot of the more ambitious requirements seem to
make a lot of sense - methods can be motivated by ping, inheritance
allows for reuse, range constraints make sense for IPSec, 
cardinality constraints carry vital information, exceptions are
a powerful error handling model, etc.  I could go on, but I think it 
is clear that there are a lot of good arguments for each of the 
ideas above.  However, the combination of these requirements 
taken together is very worrisome.

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

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

#45-46: Associations and cardinality - these are two more ideas that
on their own make good sense, but seem to complicate the big picture.
How would cardinality be captured in a mapping to SNMP or COPS? 
Pointers seems pretty easy to map to these protocols - but where does
associations fit in?  These two are elegant tools, but I think in
this context, since we already have pointers, and two pointers in
a table can model an association, simplicity says remove these
two requirements.

Finally, if I were brave enough to try to satisfy the above mentioned
requirements in SMIng, doing so and expressing the relevant syntax in 
ASN.1 sounds extremely painful - if we must go down this path, lets do 
it using something C++, or Java-like - that would at least give a 
syntactic foundation that is relevant to writing a programming language.

Other miscellaneous requirement comments:
#33: Attribute Groups - Methods are strongly associated with classes 
in the programming language lexicon, so choosing a different name is 
a good idea.

#34: Single Inheritance - As long as we avoid methods, ctors/dtors,
exceptions, etc., then single inheritance is not only useful but
feasible as well.

-David

David M. Putzolu	     Sr. Architect, Internet Infrastructure Group
David.Putzolu@intel.com          (503) 264-4510, FAX (503) 264-3483


------- end of forwarded message -------