MOO-cows Mailing List Archive
[Prev][Next][Index][Thread]

[DESIGN] Re: verbing properties again

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.
Follow-Ups:
Home | Subject Index | Thread Index