Re: Non-Database Format

=2D----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Saturday 06 December 2003 08:46 pm, Gavin Lambert wrote:
> At 16:37 6/12/2003 +0000, Luke-Jr wrote:
> > This could get very messy for large projects with possibly hundreds
> > of objects. It would probably work for interactive editors (such as
> > most MOOs are today), but that would work fine with a database
> > too, so it defeats the purpose of having a readable format.
> Personally I think it would be more messy in the case where you've
> got hundreds of objects when you want to modify two of them
> simultaneously.  Instead of having two files open to the correct
> places (so you can easily swap between them as you edit), you'd
> only have one file which you'd continually have to scroll back and
> forth.
Never thought about it this way, though it is always quite possible for=20
editors to support opening the same document up to multiple locations at th=
e=20
same time...
>
> Source code is always more readable when you have lots of little
> files rather than few large files.  And if you're writing a
> compiler anyway, then the number of source files doesn't affect
> the end user at all.  If you're doing an interpreter (or only
> compiling but not linking, like Java), then just support zipping
> up all the files into one archive (a la .jar files) and running
> direct from there, and things should be easily manageable from the
> end-user's perspective.
True, but you might want to note that Java is compiling to an emulated CPU,=
 so=20
it is effectively interpreting it too. ;)

>  >Is there a reason to use in-MOO-world syntax over MOO language
>  >function calls?
> Not any huge reason; it's just that I think people are more
> familiar with the in-MOO syntax, so the learning curve would be
> slightly shallower that way.  And since they all begin with an '@'
> it might make it easier to parse or preprocess such commands.  No
> biggie, though.
All current MOO programmers should also be familiar with add_verb and such=
=20
too... I just think introducing the @ outside of user-space will be creatin=
g=20
two languages in one...
>
>  >My idea didn't require object numbers or require the
>  >compiler/interpretor to use them. It was simply using
>  >#var to insert a reference to the 'var' variable in the
>  >main "program" (which in the example was only objects).
> It's just that I don't really like the way '#' is used both for
> object numbers (#-1) and to reference global variables (#myobj),
I'd rather not think of them as global variables, as there really is no=20
'global' area... In running the source (whether during compile or=20
interpreting), they would be *replaced* in the program code. Basicly, the=20
equivalent of doing this in a call to set_verb_code:
	" + toliteral(myobj) + "
> and sometimes they needed the prefix and other times they
> didn't.  I would think it's slightly truer to regular MOO code if
> your global variables:
>    (a) must always be referenced with a '$' prefix ($myobj),
> whether in the "main program", verb/property creation, or verb
> code
>    (b) can only be used to reference an object, not hold some
> other value
Those might be logical if it was truly a global variable, but as explained=
=20
above, they are not. Also note that $bla stuff has never been restricted to=
=20
objects. For example, $name returns a string.
>
>  > > - 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 command line or using it for saner
>  >purposes (toggles, etc).
> Well, again it depends on whether you're writing a compiler or an
> interpreter.  If a compiler (so it produces a single .exe at the
> end)
Or, in most cases, a single ELF that is +x
> , then you could specify the main object on the command line=20
> of the *compiler*, meaning no command line would be required when
> actually running the code.
True, but then we get into the mess of needing compile scripts. I'd rather =
not=20
require the compilation need anything more than a simple 'gcc myproject.moo=
'=20
if possible.
>
>  >This would require another file format for a manifest.
> True, but you could have other useful information in a manifest as
> well, such as information on the author and where to obtain the
> latest version.
Which should instead be in the README file...
> If you have (as you suggest later) a compiled=20
> core, then the MOO server could even periodically check for and
> download the latest version of the core, so you can easily get
> bugfixes.
No reason version and URLs can't be programmed right into the core or loade=
d=20
from a configuration file...
> (Probably not automatically install it, since that way=20
> lies madness.  But autodownloading would make it a little easier)
Moreso the reason for not automaticly installed would be the possibility th=
at=20
it could break some code not included in the core...
>
>  >What do you mean by a persistent database? I am looking at this as
>  >a way of writing new applications at the OS-level (while maintaining
>  >compatibility with the existing MOO-world stuff).
> Persistent as in the MOO sense, where the database hangs around
> all the time, and each time verb-code is run it modifies/acts on
> the same database, thereby allowing you to keep persistent state
> across executions.
Now I don't remember the original question...  =3Dp
Sure, this could be possible as long as only properties are modified (or it=
 is=20
interpreted). Otherwise, the program will depend on a compiler object to=20
provide set_verb_code and similar verb-oriented tasks.
I don't think it is good to automaticly keep the state persistant, however,=
 as=20
LambdaMOO does. The program will need to call dump_database()  manually to =
do=20
this.
=2D----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (GNU/Linux)

iD8DBQE/0kqqZl/BHdU+lYMRAupJAJwKsJMwt4MmlMd+bxjAMDAaLcXYXgCfd+tc
uHVHwQn0OwnKIDESbroXgoI=3D
=3DWpnF
=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