# verbing properties again

Michael Moore (mike@mail.datasys.net)
Fri, 26 Jul 1996 08:50:07 PDT

- Messages sorted by:[ date ][ thread ][ subject ][ author ]

    Adams, Charles wrote:
    >
    > I'll never support this ill-founded idea of invisibly "verbing" property
    > access. When I say foo.bar, I want to see the property "bar" on object
    > "foo", and not what someone decides I *should* be seeing instead.  Are we
    > going to have to design a builtin to mean "I really want the property, no I
    > really mean it, no, I don't want to go through channels, just connect me to
    > the property."

    What is being talked about here is the concept of encapsulation.  Basically,
    the idea is, "What goes on behind the scenes in this object is none of your
    business.  You leave the implementation of it up to me, and I'll provide you
    a nice standard interface."  The idea of it is that an object manages its
    own data, and provides public methods for access to that data.  By
    'encapsulating' the data thusly in the object, the object maintains ultimate
    control of what gets put in the actual property values.  With this kind of
    control, it becomes much easier to add things like user-defined data types
    to MOO.  It also provides a much easier way to simulate multiple-ownership
    of objects, properties, and verbs.

    Suppose, for instance, this "verbing properties" is used.  You could then
    put a wrapper around properties whose names end with '_msg'.  For the most
    part, these properties should contain a false value or a string.  Sometimes
    players get creative and put lists of strings in the properties, then until
    they correct it they see {list} where they should see that message.  The
    wrapper installed could either reject any list values for assignment to the
    property (raise E_TYPE), or convert lists into single strings.

    It is a part of OOP that college hammered into my head...and I'm glad they
    did.