Summary: Remove "negated" reqs{} field in favor of something
semantically nicer
                 Project: Freeciv
            Submitted by: persia
            Submitted on: Wed 24 Apr 2013 09:52:01 AM JST
                Category: rulesets
                Priority: 5 - Normal
                  Status: None
                 Privacy: Public
             Assigned to: None
        Originator Email: 
             Open/Closed: Open
         Discussion Lock: Any
         Planned Release: 



The semantics of the "negated" field in requirements really irritate me.  The
conditionals in the code generally require reverse polarity and
double-negative thinking.  Ruleset fragments need careful thought because
"TRUE" means that a given requirement must not be met, and "FALSE" means that
it must be met.

There are two ways to address this, either by enabling nreqs everywhere (as
suggested in patch #3332), or by changing the word used to be something
positive.  I've prepared patches achieving both, the first against trunk, and
the second against trunk + patch #3835 for consideration.  I don't believe
either is currently perfect for application to trunk, but thought discussion
might be improved with code to review.  Although the attached patches compile,
I have not tested them in gameplay at all.

I personally prefer the use of a positive term, as this better integrates with
my work-in-progress towards disjunctive requirements specification, but have
not successfully figured out a good word to use for this in the last few weeks
of thinking about it: candidates have been "present", "active", "exists",
"condition", "test", "asserted", "found", and others that I dismissed before
adding them to my TODO documentation (hence the use of the easily
search&replaceable term in the patch).  Suggestions welcomed gratefully.

Note that the introduction of nreqs uses an entirely different mechanism than
that suggested in patch #3332 (part of why I'm not reusing that ticket):
specifically reversing the polarity of ruleset defined nreqs when storing them
in the reqs vector, rather than introducing nreqs vectors everywhere (with the
need for all the attendant plumbing in requirements.c and code review of
callers).  This doesn't address the double-negation in the code, but it does
mask it from ruleset authors to some degree, making rulesets easier to both
write and read.


File Attachments:

Date: Wed 24 Apr 2013 09:52:01 AM JST  Name:
0001-Drop-negated-in-favor-of-nreqs.patch  Size: 13kB   By: persia

Date: Wed 24 Apr 2013 09:52:01 AM JST  Name:
0001-Rename-negated-to-something-positive.patch  Size: 37kB   By: persia



Reply to this item at:


  Message sent via/by Gna!

Freeciv-dev mailing list

Reply via email to