Re: terminology challenge

[Andy Bierman <abierman@cisco.com>]

At 03:14 AM 12/18/2001, Juergen Schoenwaelder wrote:

>>>>>> Andy Bierman writes:
>
>Andy> I think the WG decided not to attempt to add machine-readable
>Andy> elements of procedure, or method routines.  I think the WG
>Andy> agreed that we don't want partial inheritance, and only wanted
>Andy> single inheritance.  We aren't really providing OO features.
>
>The term partial-inheritance always strikes me. If we allow updates to
>SMIng modules, we will see some sort of partial-inheritance in fielded
>products.


This is implicit, and doesn't happen that often.  
The 'implements' clause is extra work for the writer
and reader, as is the entire protocol mapping macro.
Objects like RowStatus can simply be ignored by the COPS-PR mapping.



>Andy> I think the types of data structures we are likely to need for
>Andy> describing management information are more C-like than C++ like.
>Andy> We have examples all over the current MIBs of what should be
>Andy> STRUCTs in STRUCTs, UNION of SCALARs, UNION of STRUCTs, ARRAYs
>Andy> in ARRAYs, and many other combinations.
>
>Back to the topic: Supporting inheritance means we are using an OO
>concept which you find in C++ and Java but not in C. So I think it is
>appropriate to use some C++/Java terminology. I also believe that it
>is much more appropriate to talk about attributes rather than scalars.


The only OO feature we are choosing to support can also be
achieved in C-like syntax:

(Foo == base TYPEDEF)

TYPEDEF STRUCT FooPlus {
   DESRCIPTION 
       "Example of a subclass of Foo."

   STRUCT foo {
       SYNTAX Foo
       STATUS current
       DESCRIPTION
           "Base class Foo."
   } ::= 1

   -- add more <object-decl> clauses here...

}


>Andy> The "textual footprint" of the GenericCounter UNION is 4:1 or
>Andy> 5:1 smaller than SMIv2, without losing any semantics, while
>Andy> dramatically improving readability for (32,32/32,64) counter
>Andy> tuples. (And it matches the agent representation, making agent
>Andy> implementation easy.)
>
>Great. But what does that mean wrt. terminology?


My point is, why do we want to use C++ terminology,
when we need C functionality?  Classes derived from
other classes provides "STRUCT in STRUCT", just 1 of the many
data modelling constructs we actually need.


>/js

Andy