[Freeciv-Dev] Re: Split patch (was Re: [RFC PATCH] init_techs)

[Daniel L Speyer <dspeyer@xxxxxxxxxxx>]

On Mon, 1 Oct 2001, Reinier Post wrote:

> On Mon, Oct 01, 2001 at 08:28:44AM -0400, Daniel L Speyer wrote:
> > On Mon, 1 Oct 2001, Reinier Post wrote:
> > 
> > > On Sun, Sep 30, 2001 at 07:51:10PM -0400, Ross W. Wetmore wrote:
> > > > But I think it has been said many times that such flexibility is
not
> > > > required for Freeciv. It would be a wise move to really look at the
> > > > pros and cons before introducing such parse elements into any future 
> > > > command syntax design.
> > > 
> > > I agree, neither the ; or the ability to let commands continue on the
> > > next line seem required.  It's just nice to have.
> > 
> > It seems to me that the cases in which this could be very nice are those
> > which are concetually multiline anyways (such as oject
> > initialization).  How about allowing braces, which combine several
> > commands into an argument?  So, for example:
> > 
> > create tech.hacking { #Needed for internet
> >   set req1 computers; set req2 theology
> >   set name "Hacking"
> > }
> > 
> > Would create a namespace tech.hacking and then use it as a root namespace
> > for the following commands.  (The simplest parsing routine would probably
> > make there be four commands, the first of them of length zero.  This
> > command should simply do nothing.)
> 
> This is nice and powerful, but if it was up to me, I would prefer to
> restrict . notation to match the actual Freeciv datastructures.

So would you prefer something like "create techs[hacking]"?  In my
experience, brackets are a pain to parse.  I'm reminded of Netscape
4.x's Javascript's form handling, where fooform.elements[0]
fooform.elements["bar"] and fooform.bar were all valid.  That worked
really well (I wrote some very serious JS programs, too bad there's no
more JS-NS4.x interperators out there!)

Since each tech will have a struct holding it's internals, this isn't that
far from Freeciv's actual data structures.  It's just sort of a
combination of static and dynamic binding.  (I would seriously porpose
that before the start command all variables be kept in free-form, nested
namespaces, and that there be freeze and unfreeze commands to
permit/refuse the creation of new members.)

>  
> > --Daniel Speyer
> > "May the /src be with you, always"
> 
> -- 
> Reinier
> 
>