MOO
jayCampbell
playing...
jayCampbell
forward.
Adam Bliss
I have high hopes, but we'll see where it goes (and whether the model
holds up at all).
-abliss
On Sun, 27 Apr 2008 11:03 pm, jayCampbell wrote:
>
> Being able to create persistent objects on the fly is a huge step
> forward.
> --Adam
jayCampbell
examples of what you're doing to build out rooms?
Adam Bliss
> I'm having a hard time accessing sub-objects, can you paste a couple
> examples of what you're doing to build out rooms?
Yeah, I'm afraid it wound up being a bit more confusing than I'd
intended. If you're not familiar with prototype-based inheritance,
read up on it at wikipedia or someplace.
All Moo objects by default inherit Root:create(), so you can create
your own object anywhere unless somebody in the prototype chain
overrides create(). Once you create an object, you'll be its owner,
and you can do whatever you want underneath its umbrella. For
example, you could make a new room in my Avatar universe by mooing
'Avatar.rooms:create' and putting the label of the room in the data
field (for example, 'bakery'). Then you'll probably want your room to
inherit from the base room prototype, so you would moo
'Avatar.rooms.bakery:set' and in the data field put
'proto="Avatar.roomProto"', just like I did for Avatar.rooms.lobby.
At this point you would inherit all the basic room properties (of
which there aren't many, yet) so for example you'd be able to moo
'Avatar.rooms.bakery:look' and get the default room name and
description. Of course you could customize those by mooing, e.g.,
'Avatar.rooms.bakery:set' 'name="The Bakery"'.
Unfortunately, I don't really think the current verb-model of the Moo
system is sufficient to run an actual moo like LambdaMOO. I may have
to do some re-implementing in Avatar, but I think the outer Moo system
will be powerful enough to allow this. I'll try to preserve any edits
you make in the meantime, but no promises -- since I'm the owner of
Avatar, anything that occurs in there is subject to my whims and
errors. If it someday gets interesting and self-sustaining enough, I
may surrender ownership of it and then I'd just be an avatar with no
more power than anyone else in that universe. In this case, if
something went wrong with the Avatar universe, it would take a
ratified proposal in the outer game to fix it. At least, that's the
intention -- I strongly suspect my security model is full of holes.
One thing to note that isn't made particularly clear in the comments:
You typically address things by their labels with no underscores, but
the underlying JSON includes underscores to differentiatate a few
cases:
- no underscores: a property that can only be accessed directly, with
its label known 'at compile time' so to speak. E.g. _Avatar.owner
will always be called 'owner' and never needs to be addressed by
another name.
- one underscore: a field that can be acessed by name; the name may
only be known 'at run time'. E.g. Avatar.avatars.abliss has to be
'_abliss' because there's no way to know at compile time what the
playerId is going to be.
- two underscores: a *function* property that can be accessed, by
name, *by anybody*. Examples are create/set/delete in Root, and
'look' in Avatar.roomProto.
Oftentimes a variable in a given system could be done either with no
underscores or with one -- for example 'Avatar.avatars' could be done
as '_avatars' or 'avatars'. However, any property that's brought into
existence with Root:set(), or that needs to ever be modified by
Root:set(), will need to have an underscore. The reason for this is
that Root:set() is itself imlpemented in the "safe" moo system; this
was not strictly necessary (since it was created from an outside
proposal and cannot be modified from inside) but I did it to prove
that the system was strong enough to do useful things. So if you want
to deal in properties with no underlying underscore (such as
_Avatar._avatars._abliss.id), it has to be created and manipulated by
a function you write yourself. I did this trick in
Root._Avatar_comment (which you'll have to view-source to see) in
order to interface with the FrontEnd's toolTip system.
I hope this makes things a little more clear. Please ask questions if not!
--abliss
jayCampbell
methods, and now I'm in. I put most of your explanation into a Group
Page.
Ivan Hope CXXVII
property of something whose value is undefined; the something has to
have been __created, not set to undefined. That's why safe.set(bk._m,
etc., etc.) was failing.
--Ivan Hope CXXVII