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

[Reinier Post <rp@xxxxxxxxxx>]

On Mon, Oct 01, 2001 at 11:02:19AM -0400, Daniel L Speyer wrote:
> On Mon, 1 Oct 2001, Reinier Post wrote:
> 
> > On Mon, Oct 01, 2001 at 08:28:44AM -0400, Daniel L Speyer wrote:
[...] 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"
> > > }

I like this.

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

What I'm not sure of is whether I want 'hacking' to be a variable of
type 'tech' or a new tech named 'hacking'.

There isn't much wrong with variables, but they are not required.

> > This is nice and powerful, but if it was up to me, I would prefer to
> > restrict . notation to match the actual Freeciv datastructures.

Well, with one exception: .name fields are special.

> So would you prefer something like "create techs[hacking]"?

No, but that's just syntax.  What I mean is, it would be nice if
the construct  always specifies a path to the object within the
Freeciv data structure.

n the simplest case the path has only one member and would indicate
a top-level structure or a member of the game structure (unit_types,
techs, players, etc.)  But this is probably what your and Arien's
proposal says as well.

> In my
> experience, brackets are a pain to parse.

We only need one level, which helps.  But the . notation would be fine.
The interesting decision is whether a 'hacking' is a variable name
or a .name field value.

The {} brackets are a worse problem.

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

Did they mean the same thing?  I know PHP supports foo[0] and bar["0"]
but foo and bar are of different types (array vs. associative array).

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

This is a good idea.  Another idea is to assign access rights to them.
Sometimes players can write some of their own variables, but not those
of others.  E.g. this would be nice for the player.ailevel variable.

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

-- 
Reinier