Complete.Org: Mailing Lists: Archives: freeciv-dev: October 2001:
[Freeciv-Dev] Re: commandline syntax and semantics (was: Server/ruleset
Home

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

[Top] [All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index] [Thread Index]
To: Arien Malec <arien_malec@xxxxxxxxx>
Cc: Freeciv developers <freeciv-dev@xxxxxxxxxxx>
Subject: [Freeciv-Dev] Re: commandline syntax and semantics (was: Server/ruleset unification)
From: Daniel Sjölie <deepone@xxxxxxxxxx>
Date: Tue, 2 Oct 2001 10:00:24 +0200

On 2001-10-01 15:44:33, Arien Malec wrote:
> First, just to be clear, all my examples are about object types, not 
> instances.
> So when I wrote "unit.archers" I should have written "units.archers"
> 
> In sum, our disagreement is: I would create a new identifier to refer to
> advances, etc., whereas you would use name_orig. Not much difference, and I
> won't argue if the consensus of the list is for name_orig rather than a new
> identifier.

I'd like a identifier... Having the identifier and the displayed name
depend in a way that can't be obvious to everyone at inspection gives me
a kinda creepy feeling... :}

I think there is great potential for confusion if you do something like
the example presented with units.archers.name = "Bowmen" and
units.archers suddenly cease to exist... Brrr... :)

> It seems like the consensus of the list is to invest some work to make the
> lexer/parser flexible enough to support multi-attribute set/creates, and to 
> use
> some kind of braces/parens to group the attributes being set.

*thumbs up*

> Arien
> --- Reinier Post <rp@xxxxxxxxxx> wrote:
> > Yes, but I presented a system for quoting that would be easy to parse:
> > quote by surrounding with " ", and make ""  stand for " within " "s.
> > You do have to keep track of whether you're within quotes or not.
> > It can be made obligatory to quote names.
> 
> I agree that it can be done, but I think it's simpler to introduce an object
> indentifier. If we go your way, it should be obligatory to quote names.

Agreed... Simpler and, more importantly, clearer...
The name displayed is (as I see it) more of a label than the actual
name... Makes good sense especially considering translations...
At least to me...

> > > 2) See the following set of commands:
> > > 
> > > ; in the ruleset:
> > > create unit.archers
> > 
> > I still don't know what unit.archers is - a variable declaration
> > for the variable with the name 'archers' freely chosen by the user?
> > In that case using the . notation here is very confusing; declarations
> > are usually done like this:
> 
> Again, I intend the above command to mean "create the unit type archers"

Actually, I think it's very natural...
Compare to:
units["archers"] = ...

units.archers is simply a simpler way of writing this...

You can think of it as lists, dictionaries, maps, objects, namespaces or
whatever but I really think it makes sense and is nothing freaky...

> > > ; on the command-line, my semantics
> > > set unit.archers.name = "Bowmen"
> > > set unit.archers.hitpoints = ...
> > > 
> > > ; on the command-line, your sematics
> > > set unit.archers.name = "Bowmen"
> > > set unit.bowmen.hitpoints = ....
> > > ; Does unit.archers still exist now?
> > 
> > unit.archers doesn't identify anything now; the created object can
> > now be referred to as unit.bowmen, unless there was already a unit
> > with that name.
> > 
> > BTW the example is really about unit_types rather than units,
> > so my syntax would actually be:
> > 
> >   create units.archers  # automatically gets name "Archers" assigned
> >   set units.archers.name = "Bowmen"
> >   set units.bowmen.hitpoints = ...
> > 
> > and the mechanism is different: you introduce and use a variable name,
> > I do not.
> 
> I introduce an identifier to refer to the unit.
> 
> If I'm playing in a French locale, does units.archers.name = "Bowmen" set the
> English or the French title? I assume the English?

Like I said, I see great potential for confusion here... You shouldn't
have to read freeciv_hacking_guide to change rulesets...

> > Brackets can also be used (a la Pascal's WITH) to allow local
> > abbreviations for set commands:
> > 
> >   set techs."Atomic Theory" {
> >      req1= ...
> >      req2= ...
> >      name = "Atomic Enegry Technology"
> >   }
> > 
> > This way you don't need any variables at all.  The set and create
> > syntax is identical; the only difference would be that 'create'
> > requires the indicated object to be new, while 'set' requires it
> > to exist already.
> 
> If we force the bracket to be introduced on the same line as the create/set
> command, we can even do away with terminating commands with ";", as the
> presence of the bracket will force the lexer/parser into a "read till
> terminator" mode. 

Super... :)

/Daniel

-- 
Now take a deep breath, smile and don't take life so seriously... :)


[Prev in Thread] Current Thread [Next in Thread]