Re: Non-Database Format

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.

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.

Likewise for the developer; there may be one or two extra steps to 
compile this way, but all they'd need to do is set up their 
favourite IDE/text editor appropriately and everything should be 
fine.  And there are plenty of free flexible IDEs out now, as well 
as shareware and commercial ones.

 >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.

 >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), 
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

 >> - 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), then you could specify the main object on the command line 
of the *compiler*, meaning no command line would be required when 
actually running the code.

If an interpreter, then I agree, having to specify this each time 
would be too painful to live.

 >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.  If you have (as you suggest later) a compiled 
core, then the MOO server could even periodically check for and 
download the latest version of the core, so you can easily get 
bugfixes.  (Probably not automatically install it, since that way 
lies madness.  But autodownloading would make it a little easier)

 >The general syntax of MOO is better (IMO, at least) than most 
other
 >languages.

No argument there.

 >I'm not aware of any language in which one could do anything 
like
 >"for a in ({1,7,4,5,7})" in a single line.

I'm reasonably certain that you can do that in Perl (I'm not a 
Perl programmer so I couldn't say exactly how); and I'm quite 
definitely certain that you can do it in PHP.  You can also do it 
in C#, though the syntax is a little messy.

 >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.

-- 
Gavin Lambert, Mirality Systems
<http://www.mirality.co.nz/>
----
He who is flogged by fate and laughs the louder is a masochist.



-------------------------------------------------------
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