[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Some additional obscure questions...



Hi Dave,

>It is a "better example", not a better "coding convention". It is
>a better example because it makes a forward reference to parentOfA.
>A MIB compiler that didn't support forward references would
>support the first example, but not the second. Thus, the second
>example tells us more about the capabilities of the MIB compiler
>than the first.

Ok.  But if including the forward reference
is not a better coding convention, why should
a MIB compiler support it?

IMHO:  One cannot reasonably say that writing
the example below that avoids the fwd ref is
more difficult than the one that avails itself
of the fwd ref, so ease of use is not the reason.
And, for conceivable examples where it might be
"easier" to construct a MIB with such fwd refs
(than building the supporting base beforehand),
from the perspective of coherency of overall
MIB design, it seems that fwd refs (1) are not
necessary and (2) lead to design complexity
(of the ugly kind) with ancillary negative
impacts on other aspects of the overall mgmt
infrastructure.

So, why would you (the general "you") want to
see fwd ref support in a MIB compiler?

Thanks,

BobN
- - - - -
>At 03:12 AM 1/31/2003 -0500, Bob Natale wrote:
>>At 1/31/2003:12:50 AM, David T. Perkins wrote:
>>
>>Hi Dave,
>>
>>>> ...
>>>>   AnotherModule DEFINITIONS ::=
>>>>   BEGIN
>>>>      IMPORTS
>>>>         parentOfA FROM NON-AMBIGUOUS-MIB
>>>>         a FROM M1 { parentOfA 1 }
>>>>         a FROM M2 { parentOfA 2 }
>>>       ...
>>>    END
>>>
>>>or better yet...
>>>   AnotherModule DEFINITIONS ::=
>>>   BEGIN
>>>      IMPORTS
>>>         a FROM M1 { parentOfA 1 }  -- a forward reference
>>>         a FROM M2 { parentOfA 2 }
>>>         parentOfA FROM NON-AMBIGUOUS-MIB
>>>       ...
>>>   END
>>
>>Why do you consider the second form better
>>than the first?
>>
>>Cheers,
>>
>>BobN 
>Regards,
>/david t. perkins