# "verbing properties" and related issues

Erik Ostrom (eostrom@research.att.com)
Thu, 1 Aug 1996 13:15:42 PDT

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

    I am extremely unlikely to implement "verbing properties" (i.e.,
    altering the '.' operator to call a verb on the object), at least in
    its traditional form.  The point's been argued to death, but I'll say
    it once more:  Properties are state; verbs are behavior; if you want
    behavior, call a verb; if you want to force behavior, force a verb
    call.

    ....  The fatal flaw in this argument, of course, is that you _can't_
    force a verb call with the current semantics of the language.  Try as
    you might, properties are always readable and settable directly by any
    verb that you own or that is running with your permissions, or by a
    wizard.  Admittedly you and the wizards can usually avoid this
    mistake, but it's still a problem.  _This_ I would like to see
    changed, although I have no immediate or definite plans for it.  But I
    don't think undermining the semantics of property reference is the
    right way to provide encapsulation.

    [I'll save Brandon the trouble of repeating himself:  ColdC already
    offers complete encapsulation of state, so that _all_ state access
    between objects _must_ occur via (its equivalent of) verb calls.  I
    think this is great; however, I consider it a major language change
    from MOO.  I would encourage people who want a language this different
    to lend their efforts to the ColdX project, at <http://www.cold.org/>
    --not that MOO never changes, but it has less freedom to change
    quickly and dramatically.]

    Janus suggested, and Seth heartily concurred, that foo.bar be treated as
    an implicit call to a new function [set_]property_value(), which could
    then of course be protected and wrapped like any other function.  This
    seems marginally more tolerable to me.  On the other hand, I'm not
    entirely comfortable with 1.8's function-wrapping stuff anyway (for
    roughly the same reasons I dislike verbing properties).  So I guess
    I'm deferring any action on this to some unspecified later date.

    ThwartedEfforts proposed a wait() function, which would allow code to
    be run _after_ a property is set.  I like this, in that it allows
    programmers to get rid of wait loops, without upsetting the
    expectations of code that sets properties directly.  However, I
    suspect that the portions of this that are implementable in-db
    (primarily, it probably has to be limited to specific properties with
    getter/setter methods, rather than being available for any arbitrary
    property) are sufficient.  Has anyone tried this in earnest?