Re: Non-Database Format

At 21:31 6/12/2003 +0000, Luke-Jr wrote:
 >
 >Never thought about it this way, though it is always quite 
possible
 >for editors to support opening the same document up to multiple
 >locations at the same time...

Yes, and most good ones do.  I just think it's more of a hassle 
than having multiple files -- apart from everything else, you have 
to go looking for the object you want.  Instead of being able to 
say "well, object foo is in foo.moo and object bar is in bar.moo", 
you'd have to either remember "object foo is somewhere around line 
1135, and object bar is around 9922" or do a search each time, 
which would get you a number of "false positives" (where the 
object is referenced) unless the search was phrased exactly right.

 >True, but you might want to note that Java is compiling to an
 >emulated CPU, so it is effectively interpreting it too. ;)

Hence why I said it could skip the link step.  And you'll note (if 
you re-read the original post) that I grouped Java in with the 
interpreted languages, for exactly that reason.

 >All current MOO programmers should also be familiar with 
add_verb
 >and such too... I just think introducing the @ outside of 
user-space
 >will be creating two languages in one...

Perhaps they'll know vaguely that they exist, but unless they've 
been wizards on some MOO somewhere they won't have ever used them 
-- since often add_verb etc are restricted to wizzen.  Whereas 
everybody has used the @-verbs, and most existing moo-code scripts 
(both generated from @dumps and manually created) also use them.

 >I'd rather not think of them as global variables, as there 
really
 >is no 'global' area... In running the source (whether during
 >compile or interpreting), they would be *replaced* in the 
program
 >code. Basicly, the equivalent of doing this in a call to
 >set_verb_code:	" + toliteral(myobj) + "

This strikes me as being even more nasty than global variables -- 
but perhaps I'm just being overly pedantic, or misinterpreting 
you.  Or both.

 >Also note that $bla stuff has never been restricted to
 >objects. For example, $name returns a string.

Yes, I know that.  But it's ugly.  I'm one of the "avoid global 
variables" crowd, though I think that object names are a special 
case and should be treated similarly to a global variable, though 
there's no need to call them that, of course :)

 >> If a compiler (so it produces a single .exe at the end)
 >Or, in most cases, a single ELF that is +x

Well, yes, but since I'm predominantly a Windows programmer (since 
it pays the bills) I tend to think of .exe files.  Doesn't really 
make much difference.

 >True, but then we get into the mess of needing compile scripts. 
I'd
 >rather not require the compilation need anything more than a 
simple 'gcc
 >myproject.moo' if possible.

Well, one way around it (though personally I think it's a bit of a 
kludge) would be to refer to the single main .moo file you want on 
the command line, and have that "import" the other files it 
needs.  Something like this:

main.moo:
   @import foo.moo
   @import ../lib/bar.moo
   @create $foo $baz         (or "$baz = create($foo);" if you 
prefer)
   ....

Then you could just "gcc main.moo" and it would haul in the extra 
files it needed.

 >Which should instead be in the README file...

No reason it couldn't be in both.

 >No reason version and URLs can't be programmed right into the 
core
 >or loaded from a configuration file...

So the core itself has to contain code to check for a newer 
version and download it?  Seems like more of a hassle, and you'd 
end up with some cores doing that and others not; very 
inconsistent.

 >Moreso the reason for not automaticly installed would be the
 >possibility that it could break some code not included in the 
core...

That's why I said that "that way lies madness."

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