Large mechanical translation patch: ist_XXX to is_XXX

[neroden]

I was hoping to generate an even more massive translation patch for ribi.h, but I realized that I couldn't quite get it together yet.  This will, however, be an improvement and simplify future method name translation.

This patch replaces all ist_XXX methods with is_XXX methods, in the spirit of partial translation which produced the 'get_' and 'set_' methods.  I think "is_" is a standardized prefix like "get_" and "set_" so this is appropriate.

The patch itself is at http://files.[ simutrans [dot] us (site down, do not visit) ]/files/get/jLA6mOw9yT/ist-to-is.diff

It was actually generated on Linux by a shell script using 'sed', which is at http://files.[ simutrans [dot] us (site down, do not visit) ]/files/get/RxQj9g6S01/short-translate.sh 

The script took a while to get right.  If there's any code change before this goes in, it is better to use this script.  The script is also the correct way to update 'experimental' to match the changes (which I will do if the changes go into standard).  The script can be safely run repeatedly.

[prissi]

Unfourtunately this situation is not as good as with get/set: ist_, is_ and has_ exist, all meaning the same.

I think one should first put some considered patches in before executing this ... so this should be done right after a release. For this, I'll put in into considered.

[neroden]

Unfourtunately this situation is not as good as with get/set: ist_, is_ and has_ exist, all meaning the same.

I think one should first put some considered patches in before executing this ... so this should be done right after a release. For this, I'll put in into considered.

OK!

is_ and has_ mean slightly different things in English (a piece of track is_diagonal, and it's wrong to say that it has_diagonal, whereas a piece of track has_signal, but it is wrong to say that the track is_signal).  That's why I didn't merge those.

EDIT:
The difference in English is mostly whether the word is an adjective or a noun.  "is_adjective" vs. "has_noun".

You would use "is_noun" only for things like "a road vehicle is a vehicle" which are represented by class hierarchies already.

So you could change them all to "has_" by using "has_diagonalness" instead of "is_diagonal".

[jamespetts]

I find syntax such as "is_diagonal" much easier to understand than "has_diagonalness" (sic).

[VS]

Standardizing on one prefix will help the code, not English language... but this is code after all

Off topic: seeing tons of get_ & set_ makes me like my Delphi more. Properties!

[jamespetts]

Standardizing on one prefix will help the code, not English language... but this is code after all

Off topic: seeing tons of get_ & set_ makes me like my Delphi more. Properties!

Likewise C#

[prissi]

These are intenionally made private to make sure than when sometimes set_xyz needs to do more than just to alter a value it can be done. You can firend verything like in C#. OR did I misunderstood.

And I agree to VS: This is code, thus querying should get one prefix. Even more since there are some has_diagonal() and is_moving() in the code imho.

[VS]

Perhaps instead of "is" and "has" one could call it "query" and avoid ambiguity/language massacre. (But that is a lot of letters for prefix... maybe "qry" ? ) Alternatively, it could all be summed into get_, although I can see why that seems like a step back.

prissi: friending etc. - misunderstood Properties are "fake variables" with getters and setters. You write code as if it was normal variable (window->caption = "hello") but it gets executed as call (window->set_caption("hello")). The nice thing is that without need for prefixes visible outside, all names are uniform.

[neroden]

"is_" and "has_" convey useful information which "get_" doesn't.  "is_" and "has_" always return boolean values.  "get_" doesn't.  That's why changing them to "get_" is a mistake.

[jamespetts]

From what I understand, "Is" is the conventional way of specifying a getter for a boolean value.