[Freeciv-Dev] Re: commandline syntax and semantics (was: Server/ruleset unification)

[Arien Malec <arien_malec@xxxxxxxxx>]

--- Reinier Post <rp@xxxxxxxxxx> wrote:
> To denote an object, you could use
> 
>   + field names (eg. 'ailevel', 'players')
>   + the value of the 'name' field or a case-insensitive prefix (eg. 'Eliz')
>   + with lists, index numbers (eg. '5')
>   + with lists, syntax to denote the last and (last+1)-th element
> 
>   + rules to omit full path names in contexts where they can be derived

Since the first object is to unify ruleset and command line syntax, we don't
need to do anything except for the case insensitive indentifer, IMHO. Later,
when we want to unify savegames, etc. it  may be necessary to make it more
complex. But I'd recommend keeping it really simple for the moment.
 
> If names are always unique within lists (city names usually are, but
> not always), then using names instead of index numbers isn't
> ambiguous.  If they are unique across types (eg. no ruler and city have
> the same name) then using names is never ambiguous even in abbreviated
> syntax.  Such ambiguity will rarely arise in practice, but it is better
> to support it in order to support the use of prefixes.

Rulesets & command-line syntax don't need to worry about cities. Savegames
will, but this is a later stage. So I think we can assume that every object can
have a case insensitive identifier, and we don't need to worry about numerical
indexes.
 
> I don't think the use of . syntax for all these cases will lead to
> serious problems.  It complicates syntax checking a little, but
> not very much.  It may be better to require ""s around names,
> and/or to use using []s around index numbers; that way you would
> have game.players."5" and game.players[5].

Having all sorts of aliases for the same object definitely complicates the
parsing. If the first component of the name (e.g., tech.greek.... or
tech[greek]....) lets us dispatch the right handler, the toplevel parsing code
can be really really simple. If it has to realize that game.nation.english is
the same as game.player.liz.nation is the same as player.liz.nation is the same
as nation.english ....

> A distinction must be made between pointers and their values
> (usually objects or lists).  This is only important when a
> pointer is used as the right hand side in an assignment:
> 
>   set "Dresden".worklist = "Leipzig".worklist
> 
> may mean that Dresden gets a copy of Leipzig's worklist, but
> it may also mean that it gets linked to the same worklist.
> I think it's best to indicate the latter case by using the command
> 
>   link "Dresden".worklist = "Leipzig".worklist

I'd avoid letting other objects be on the right hand side for the moment. The
current command line and rulesets don't allow it. After we get that done, we
can make it more complicated.

> I think it's cleaner to use
> 'link'/'set' instead of 'set'/'create'.  You can fill objects with
> default fields in the 'set'/'link' system just as well.

I don't understand this? If I issue:

set tech.railroad.name "Railroad"

And the railroad tech doesn't exist, should it be automatically created? That's
going to lead to lots of bad objects due to typos, IMO.

Better to issue a create first:

create tech.railroad
set tech.railroad.name "Railroad"

Arien

__________________________________________________
Do You Yahoo!?
Listen to your Yahoo! Mail messages from any phone.
http://phone.yahoo.com