# verbing properties again

Ninoles, Fabien: DGSE (ninoles.fabien@ic.gc.ca)
Fri, 26 Jul 1996 17:29:50 PDT

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

     ----------
    From:  Michael Moore[SMTP:mike@mail.datasys.net]
    Sent:  Friday, July 26, 1996 8:50 AM
    To:  Adams, Charles
    Cc:  MOO-Cows
    Subject:  Re: verbing properties again

    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.

    Agree with that... I'm using a kind wrapper around some
    properties to let it choice a the French or English version
    of a string depending a language property set on the player
    variable. But I continue to find that good encapsulation
    can be done with -r property and put some access-controlling
    verb around.

    Sometime verb have to rely on the consistencies of their
    properties. Change in the behavior of one of the ancestors
    property-verb can make it return a list in place of a
    string... and make all their children OOF (out of function if
    you prefered ... ).

    Maybe some scoping value like in C++ (see private, protected
    and public) can be made to look if only the objects, their
    children or everyone can access directly to some properties
    of the object but I would put it first in some security
    meaning like for -x verb but for wiz or caller_perm(). This
    will help to "securise" the server and having all this
    security check done in server can, *I think*, reduce the
    lag considerably...

    That just another 2 pennies in this begin-to-be-long-but-still-
    interesting thread.

     ---------------------------------------------------------------
    The
    contradiction is not that free software are among the best,
       it's that
    commercial software aren't the best of
    them.
    ===============================================================
    Fabi
    en Ninoles aka the Baggus Mage aka Baffouille
    ninf01@gel.usherb.ca
                +-----------------------------
    finger me for my PGP Public
    Key  | Not knowing where you go
                                     | always
    lead you to
    [space must be fill to register] | a Baggus
    End...
    ---------------------------------------------------------------
    Can
     be reach too on Ninoles.Fabien@ic.gc.ca until
    23/08/96
    ---------------------------------------------------------------