Re: Non-Database Format
Luke-Jr <[email protected]> Sat, 6 Dec 2003 16:37:48 +0000
| Newsgroups | gmane.comp.lang.moo.general |
|---|---|
| Message-ID | <[email protected]> |
=2D----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On Saturday 06 December 2003 04:09 am, Gavin Lambert wrote:
> At 22:35 2/12/2003 +0000, Luke-Jr wrote:
> > What does everyone think MOO should use for storing programs
> > when it does not use a database (human readable)?
> My pick would be to do something Java-like (not that I'm a Java
> programmer):
>
> - one object per .moo file (perhaps a recommendation rather than
> enforced)
This could get very messy for large projects with possibly hundreds of=20
objects. It would probably work for interactive editors (such as most MOOs=
=20
are today), but that would work fine with a database too, so it defeats the=
=20
purpose of having a readable format.
> - abandon object numbers for "precreated" objects (still use them
> for dynamically created ones, of course); use names
> instead. Perhaps just an ad-hoc $myfoo, like so:
>
> @create #-1 $myfoo
> @verb $myfoo:bla
> @prop $myfoo.baz "bob"
>
> etc. The @create line would create a new object and call it
> $myfoo, without the need to have an actual object #0 or #0.myfoo
> property.
Is there a reason to use in-MOO-world syntax over MOO language function cal=
ls?=20
My idea didn't require object numbers or require the compiler/interpretor t=
o=20
use them. It was simply using #var to insert a reference to the 'var'=20
variable in the main "program" (which in the example was only objects).
>
> - Deciding which verb to execute first; well, you could do that
> like Java (specify it on the command line),
Doing this would effectively prevent one from running the application from =
the=20
command line or using it for saner purposes (toggles, etc).
> or you could have some=20
> sort of manifest file which tells the engine which to run first,
This would require another file format for a manifest.
> or just have inline code somewhere like you proposed. Not sure
> which of these approaches is cleaner.
>
> To be honest, though, I'm not entirely convinced of the point in
> MOO code without a backing database -- the database is part of the
> whole reason for existence of the system. Without it, there isn't
> really anything you can do with MOO code that you couldn't do
> better in some other language.=20
The general syntax of MOO is better (IMO, at least) than most other languag=
es.
I'm not aware of any language in which one could do anything like "for a in=
=20
({1,7,4,5,7})" in a single line.
> Or did you just mean without a *persistent* database? Even so......
What do you mean by a persistent database? I am looking at this as a way of=
=20
writing new applications at the OS-level (while maintaining compatibility=20
with the existing MOO-world stuff).
Not sure why, but this question did suggest an idea to me (possibly unrelat=
ed=20
to what was meant by it), but it might be possible in the future to extend=
=20
the LambdaMOO server to use precompiled cores and store only userland objec=
ts=20
in a database. This might hurt MOO-worlds because it would be harder to=20
change the core (and therefore be undesirable in some cases), but it would=
=20
also allow worlds who only build on an existing core to upgrade the core=20
without much effect on the rest of their world.
=2D----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (GNU/Linux)
iD8DBQE/0gXgZl/BHdU+lYMRArMyAJ9rb709JElRiOX3NxdhFou5jAPP/QCfchTq
azeuIb6evwKKsughmOl9sLU=3D
=3DKmzA
=2D----END PGP SIGNATURE-----
-------------------------------------------------------
This SF.net email is sponsored by: IBM Linux Tutorials.
Become an expert in LINUX or just sharpen your skills. Sign up for IBM's
Free Linux Tutorials. Learn everything from the bash shell to sys admin.
Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click