RE: Methods in the NIM requirements

["Andrea Westerinen" <andreawest@mindspring.com>]

I totally agree with Lakshmi.  Attributes represent state/data (ie,
DeviceIsLocked boolean, CurrentNumberOfQueues guage, etc.).  This should be
defined as properties in the info model.  It is very reasonable to have
public data in an OO design.  Methods represent behavior and change state
(ie, InitializeDevice, Reconfigure, etc.).

To mix the concepts of data and methods ends up with data acting as a method
(ie, write property x, hope that it takes, come back later to verify, if the
value changed was it because of the write or something else), or (OTOH)
methods that are very numerous and/or cumbersome.

A word of caution - Don't mix different implementation views (all data, all
methods, or various mixes of data/method combinations) into the info model
view.  An info model is (by definition) repository and implementation
independent.  That indicates that we should define the right level of
"public" data and the right methods to reflect behavior and change state.
Then, the various implementations should map these to what they understand
and require.

Andrea

> -----Original Message-----
> From: owner-nim@ops.ietf.org [mailto:owner-nim@ops.ietf.org]On Behalf Of
> Lakshmi Raman
> Sent: Saturday, April 22, 2000 2:28 PM
> To: Weiss, Walter
> Cc: Joel M. Halpern; nim@ops.ietf.org
> Subject: RE: Methods in the NIM requirements
>
>
>
>
> Walter
> I do not think it is correct to say that we do not need
> attributes if we have
> methods.
> They are both needed. Often attributes represent states that an
> object goes
> through
> when different methods are invoked and these are properties that should
> be readable.
> Lakshmi
>
>
>
>
> "Weiss, Walter" <WWeiss@lucentctc.com> on 04/19/2000 04:22:15 AM
>
> To:   "Joel M. Halpern" <joel@ivyplan.com>, nim@ops.ietf.org
> cc:    (bcc: Lakshmi Raman/Telcordia)
> Subject:  RE: Methods in the NIM requirements
>
>
>
>
> > When I build actual objects, I almost always hide the attributes
> > completely, and use specific accessor operations.  But that
> > is not because
> > I want to hide the existence of the attribute.  It is because
> > the languages
> > all end up exposing more than just the attribute when I expose an
> > attribute.  To retain my flexibility of implementation, I
> > hide that under
> > an accessor.  But in the kind of information model we are
> > talking about, we
> > do not have this drawback.  So we can use the power of both
> > the attriubte
> > semantics and the operational (method) semantics where each
> > is appropriate.
>
> Joel,
>
> It would seem then that attribute constraints are unnecessary because the
> the method definitions provide those constraints as part of their
> definition. Why bother defining attributes at all if you have method
> definitions to specify the behavioural boundaries of the object?
> As you say,
> the attribute definitions within an object define a specific
> implementation
> of the object that is immaterial to the interface definition.
>
> regards,
>
> -Walter
>
>
>
>
>
>