MOO-cows Mailing List Archive

[Next][Index][Thread]

"verbing properties" and related issues



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?


Follow-Ups:

Home | Subject Index | Thread Index