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

Re: "verbing properties" and related issues

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