# [DESIGN] Re: verbing properties again

ThwartedEfforts (abakun@scinc.com)
Fri, 26 Jul 1996 09:20:05 PDT

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

    At 08:50 AM 7/26/96 PDT, Michael Moore <mike@mail.datasys.net> wrote:
    >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.

    Please, don't tell Chuck about OOP.  Trust me, he already knows. :) :)

    >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.

    Exactly.  So you should make the props !r and provide accessor methods.  But
    it should not be done invisiblity.
    Perhaps part of the problem that MOO uses non-standard (as if there is a
    standard) terms.  '!r' really means 'private'.  Also, so far, it's only been
    mentioned that ALL property accesses would go through some wrapper, even
    those on the object on which the property is defined.  The methods on the
    object that defines the property should have complete and total and direct
    control (of course, it is commonly a good design decision to still access
    through wrappers, but it's just that: a design decision, I should still be
    able to get at the raw value if I want).

    >By
    >'encapsulating' the data thusly in the object, the object maintains ultimate
    >control of what gets put in the actual property values.

    Always via the accessor methods or via any of the methods on that object?

    >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.

    But forcing all accesses to go through accessor methods is crazy.  You can't
    design good programming practices into the system, people have to want to do
    things a certain way.  In some cases, the certain way will be direct
    property access everywhere.  In other cases, the certain way will be to go
    through accessor methods.  Unfortunately, the most widely used core database
    for MOO is not programmed in an OO fashion, so we have the problems we have
    today.

    >Suppose, for instance, this "verbing properties" is used.  You could then
    >put a wrapper around properties whose names end with '_msg'.

    This is commonly done anyway, which is why many LambdaCore objects have a
    single verb with a bunch of aliases ending in "_msg".

    Andy.