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

Wish List

Erik Ostrom wrote:

> On that subject, I'd like to express my admiration for Pavel, who has
> been astonishingly organized and capable at this for the last six or
> so years, and my gratitude to him for developing this software and for
> giving me the opportunity to try to live up to that.

Howdy!  :)

>
> Now, on to being heard from:
> > I'd like to know what kinds of plans he has for the server in the future
> > (not necessarily the near future ;) etc.

<snip>

>   Database-accessible features:
>
>   * Dictionaries (aka hash tables):  Data structures that map a set of
>     "keys" onto a set of values.  We can do this right now with
>     association lists, but they're inefficient and in some ways not
>     very pretty.  Also, they make it easier to do:

I'd like to see these implemented in the fashion they are used on LPMOO.
Basically, a table literal is {<key> ~ <data>,<key2> ~ <data2>,...}.
To retrieve a value by key, you use table[key].  Key can be of ANY type,
though Rob Leslie recommends using only simple data types.
These tables can be spliced like lists.  It would also be really cool if
splicing a table into a list resulted an an associative list, i.e. a list
of {{key1, data1}, {key2, data2}}.
If it could be done so that a LPMOO database that has properties using
this type could load, that would be Wonderful...though I'm not really
sure if it is feasible...  LPMOO also implements floating-point numbers
but they may not use the same type code in the text database...

>
>   * User-defined aggregate data types (aka lightweight objects, aka
>     garbage-collected objects, aka "frobs").  Rather than go into
>     this subject here, I'll refer you to
>       http://www.cold.org/ColdC/Structure/types.html#frob
>     for the ColdC (formerly ColdMUD) version; also see the
>     discussion of method call, in the "expressions" section.
>     MOO frobs will not be exactly like ColdC frobs, even assuming
>     I do implement them, but they'll be close.  I expect we'll
>     discuss this more as time goes by.
>
>   * (I used to think that, along with frobs, we should be able to
>     define methods on the built-in data types, so that _all_ data
>     can become "active", knowing how to respond to certain verb calls,
>     and so on.  I'm less convinced of that now, but it's still a
>     possibility.)

Now, these would be a most excellent addition to MOO.  :)

> Among the ideas from Pavel's 1.8.0 features list that didn't
> get implemented, the ones that appeal to me most are verbdefs
> (persistent handles for verbs) and foo:bar/call_proc (splitting verb
> lookup and call into two separate actions).  I don't consider those
> central, and I've got plenty on my plate already, but they give
> another idea of the sort of thing I'm interested in.  The features
> list is at
>   http://forney.scinc.com/~abakun/moomail/94a/msg00261.html

Verbdefs would be nice...also, I remember something about properties
being renamed.  I like that idea.  Now, if it wouldn't be too off-the-
wall, what about allowing properties, like verbs, to have multiple
names?

Someone in another post mentioned binary strings.  LPMOO uses "buffers"
which, I believe, are what that person wants.  Would you be interested
in using LPMOO's conventions to implement this?  I noticed that your
email is at ccs.neu.edu...as is LPMOO's maintainer.  Do you know Rob
Leslie?

And, if you do use LPMOO-style buffers, could you expand on them and
allow index() and match() to work with them, interchangeably with
strings?  What about concatenation?  It'd be nice to be able to use
+ on two buffers...perhaps even have the concatenation of a string
and a buffer automatically convert the string to a buffer and return
a buffer as the result?

> In addition, I'd like to get to know my users a little--at least, I'd
> like to be familiar with those of you who are running MOOs, and with
> the kinds of MOOs you're running.  I know only a few of you, and I know
> there's a lot out there.

I help run a RP MOO called Star Stones.  We're using LPMOO, which is a
Wonderful Thing as far as process size goes...but we're starting to have
more than 20 simultaneous connections regularly, in addition to being an
E_MOO Web Server (Thanks again, TEf!) and it just gets too laggy...so,
we're gonna move it to WinMOO.  I'd love to be able to move it to Lambda
MOO, but that's just not possible for me right now.  :)  But, since WinMOO
is based directly on the Lambda source...the maintaner says it will stay
parallel to Lambda.

One more thing--I'm sure this has been argued about before...but, could
you make it so that the boolean value of an object dbref is equal to
the result of valid(object)?  Perhaps, if a lot of people have written
code that counts on object values being false, it may be nice to put an
option on $server_options for it...

Nice to meet you!  And thanks for the chance to throw my two pennies into
the wishing well...  :)

> Thanks
> --Erik

Thank you!

--
                          Michael Moore

e-mail                - mailto://mike@mail.datasys.net
Star Stones MOO       - telnet://mserv1.wizvax.net:9999
Blatant Commercialism - http://www.freedomstarr.com/MO1318186.rep
Home | Subject Index | Thread Index