# "verbing properties" and related issues

thomas@xs4all.nl (thomas@xs4all.nl)
Fri, 2 Aug 1996 07:34:04 PDT

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

    On Thu, 1 Aug 1996, Erik Ostrom wrote:

    > ....  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 agree. Programming in MOO wil always mean cooperating with the other
    programmers, or in the very least their objects. If you rip the value of a
    property out of the properly directly, instead of using the verb that was
    created specifically for that job, the value of the prop might change
    (from a float to a list of floats, for example) and your verbs would
    break, whereas using the right verb might (/might/ - depends on the
    other programmer of course:) prevent that.

    This is exactly the reason Multiple Inheritance will not work in a MOO -
    besides the fact it is much less necessary in MOO than in most OO
    languages. C++ needs MI because it can't string 'classes' together, like
    MOO can (As far as i know, i haven't studied C++ that much, yet)
    C++ can handle MI because it just won't compile if there are errors
    (methods defined on more than one parent, for instance) and the programmer
    would have to edit it. A MI MOO object might run fine, but if some other
    programmer alters one or more of the parents, the whole thing might stop
    working, or worse, give slight errors or destroy a database that has
    been worked on for months (provided you do that in your MOO, without
    making backups :)

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

    Provided the addition doesn't overtax the server. Like Kipp said:

    PS. In a one-minute period, paradigm's :_* verb was called 8107 times, and
    there were only 2 people logged in.

    I have no idea how 'difficult' it is for the server to look if a bf_()
    exists, (we'd need profiling for that :-) :-) :-)) but 8107 is a lot, even
    if you take in account the two were doing heavy programming. In the
    MetroMOO (see below) we should easily get that number of calls. (lots of
    chatting, programming, features (oh, lots and lots of them :((
    unfortunately) etc.) I'd prefer an optimized, speedy moo if it isn't too
    much trouble :)

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

    No, i've been thinking about it, very shortly, though :) I intended to
    make a kind of scheduler, not just for wait()-ing tasks, but also for
    suspend()-ing tasks, so we would have a view of what tasks were taking up
    ticks etc. However, i ran up against too much troubles :) the
    scheduler-task would take up lots of cpu, there was the trouble of a
    property changing to 1 and back to 0 before the scheduler noticed, etc.

    The best solution IMHO, would be a kind of hooks, or signals. It
    could be done in-db, but in-server this wouldn't have to take up that much
    CPU, and be much more versatile and user-friendly. A verb would call a
    hook on an event (merely a self-assigned name). A different process
    would announce the event (using the same name) and provide an optional
    value, which the hook-call would return. The signals would be
    limited to the same user, unless caller_perms is wizard, in which case
    announcing it 'moo-wide' would be optional.

    Another option would be to add a maximum time to the hook, similar to
    suspend (or even a minimum time). This would negate the nice thing about
    the hooks, though, not having to worry about them at all, until the proper
    event occurs. (Of course, kill_task would have to be changed to remove
    events-requests when it kills hooks())

    One example of possible use might be this:

    In the MetroMOO almost everyone has local-editing (due to the fact we are
    part of the Digital City, see below:) and for nearly as long as the MOO
    exists, people are complaining they can't see whether someone is editing,
    or listening, or any of the other shell-activities we provide (reading
    mail, reading news) Numerous solutions were provided (some by myself,
    even, /before/ i became wiz ;-) but none work satisfactory -- most require
    big verbs, and big alterations to very basic and often called verbs like
    'tell'. With a hook()-call in (a verb forked() by) @edit, and an
    event()-call in a simple return-verb called by the TF macros, this could
    be made very simple.

    Another thing we have, is a login-watcher -- for everyone. The MetroMOO is
    very social, and we have a system that broadcasts the logging in of a user
    to anyone who wants to know such things (determined by two properties.)
    An easy extension using the hook() and event() calls would be reacting
    automatically to someone's login, by making a MOO-wide event(), and
    enabling people to attach hooks to it. Knowing some of the users on
    MetroMOO they would make very interresting and creative use of it.

    Anyone interrested ?

    Now, about introducing the MetroMOO :)

    The MetroMOO (Originally, in dutch, De Digitale Metro (The Digital Metro))
    was set up by Michae"l van Eeden, for De Digitale Stad (The Digital City)
    - a freenet in the Netherlands (shameless plug: http://www.dds.nl)  Mieg
    has retired from the MOO, but the MOO lives on, luckily :) After more than
    two years we now have more than 2200 users. The MOO was originally set up
    as a MOO version of the Amsterdam subway, but soon it changed to a
    themeless, everyone-programmer, social MOO, with selfish, egoistical
    wizards taking up all the cool #numbers (#222, #10, #10000, #20000 :-)

    Most of our players are programmers, and we have seen lots of nice things:
    games, weird rooms, we even almost had a Startrek RPG, but the wiz that
    was building it 'disappeared' before it was over :P After nearly reaching
    50MB run-time memoryusage we installed byte-quote, and now the memory has
    dropped to 40MB, only slightly growing. The lag has disapeared now,
    too. The only thing that makes us special is that we are a dutch moo,
    connected to the Digital City, and we use NIS to authenticate the
    passwords.

    As for what extensions we'd want for the MOO, i think disk-basing would be
    very nifty, especially if one would be able to get statistics as to what
    objects get swapped. 40MB is pretty big, and we have no clue as to what
    actually takes up all that space :) As far as i can see, only a small part
    of the MOO is used at any one time (there is like, a morning, an
    afternoon, an evening, and a night crew, all different people, doing all
    different things.) We are running on machine that is also a nameserver and
    a newsserver, so we can't use too much of the memory.

    Regards,
    Thomas.