Re: Non-Database Format

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

On Saturday 06 December 2003 10:05 pm, Gavin Lambert wrote:
> 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.
Or use the object dropdown box provided by most IDEs.
>
>  >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.
The arguments aren't all that different. There's no reason why one can't=20
simply do 'add_verb(obj, "foo");' or 'add_property(obj, "foo");' if they=20
don't know the full syntax (besides that LambdaMOO only natively supports t=
he=20
full syntax).
>
>  >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.
Basicly, it's treating the entire file as a verb, but adding the '.program'=
=20
functionality to what can be used. Between '.program' and '.' (to end the=20
code for it), anything such as #somename would be translated to the literal=
=20
value of the variable 'somename'. One could always use set_verb_code to do=
=20
the same thing right now, but I think adding .program to the language is a=
=20
good idea... :)
>
>  >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 :)
Sure, but there's no actual reason to prevent it or change how it currently=
=20
works...
>
>  >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:
>=20
> main.moo:
>    @import foo.moo
>    @import ../lib/bar.moo
>    @create $foo $baz         (or "$baz =3D create($foo);" if you
> prefer)
>    ....
>
> Then you could just "gcc main.moo" and it would haul in the extra
> files it needed.
But that doesn't address what verb would be called when the program is=20
started. The ability to import other files is probably a good idea and=20
probably neccesary to implement the multiple files, though.
>
>  >Which should instead be in the README file...
> No reason it couldn't be in both.
No reason to have both if they're not needed :)
>
>  >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.
I'd rather the cores upgrade themselves than have it builtin to the=20
language... Perhaps someone will writie an automatic upgrade object that=20
people can download seperately and then all cores can support that...
=2D----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (GNU/Linux)

iD8DBQE/0l9mZl/BHdU+lYMRAk7HAJ9mOmhSEQaZFLnZavg7YXsgOHamwQCeMTIQ
f1VYMj7Tsan/vQEGR5ZtLHc=3D
=3DLwEb
=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