Re: [Freeciv-Dev] (PR#39450) Make rule names available in the scripting api
URL: http://bugs.freeciv.org/Ticket/Display.html?id=39450 Ulrik Sverdrup wrote: But we could go for consistency the other way around and change our mind and use: :rule_name() :name_translation() :plural_translation() to follow the C function names yes. follow the C function names. I choose those names to indicate the translation, no misunderstandings. Another inconsistency in our code I noticed though is that some types (like tech/advance) use the index of the type, but others use the whole struct (for example unit_type). Nothing script authors will need to worry about of course. yes. long noted in the HACKING file. I was thinking about finishing the conversion that somebody started (from index to pointer), but unlike the bug fixes in my previous patches, I'm not aware of existing bugs that are caused by the inconsistency, so I've left it alone for now. Maybe next week ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
Re: [Freeciv-Dev] (PR#39450) Make rule names available in the scripting api
URL: http://bugs.freeciv.org/Ticket/Display.html?id=39450 If we only make the translated name available, it should be clear that it is not the rule name, so it should be name_translated() No, it should be translated_name() Consistency, always consistency. You don't want to have to grep half a dozen possible function names, even in this small project. That gets rapidly tiresome, and you miss too many. I meant to type translated_name(). Now I know what to do, so I'll try to work on this soon. ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
Re: [Freeciv-Dev] (PR#39450) Make rule names available in the scripting api
URL: http://bugs.freeciv.org/Ticket/Display.html?id=39450 Attached patch v1. Also attached test .sav file, that should work by just loading it with the server, no need to even start the game. Using suggested :rule_name() :translated_name() Sorted everything in the order the types are defined, that is: Government Nation_Type Building_Type Unit_Type Tech_Type Terrain Index: server/scripting/api_methods.h === --- server/scripting/api_methods.h (revision 13101) +++ server/scripting/api_methods.h (arbetskopia) @@ -27,5 +27,19 @@ bool api_methods_building_type_is_small_wonder(Building_Type *pbuilding); bool api_methods_building_type_is_improvement(Building_Type *pbuilding); +/* rule name and translated name methods */ +const char *api_methods_government_rule_name(Government *pgovernment); +const char *api_methods_government_translated_name(Government *pgovernment); +const char *api_methods_nation_type_rule_name(Nation_Type *pnation); +const char *api_methods_nation_type_translated_name(Nation_Type *pnation); +const char *api_methods_building_type_rule_name(Building_Type *pbuilding); +const char *api_methods_building_type_translated_name(Building_Type + *pbuilding); +const char *api_methods_unit_type_rule_name(Unit_Type *punit_type); +const char *api_methods_unit_type_translated_name(Unit_Type *punit_type); +const char *api_methods_tech_type_rule_name(Tech_Type *ptech); +const char *api_methods_tech_type_translated_name(Tech_Type *ptech); +const char *api_methods_terrain_rule_name(Terrain *pterrain); +const char *api_methods_terrain_translated_name(Terrain *pterrain); #endif Index: server/scripting/api.pkg === --- server/scripting/api.pkg (revision 13101) +++ server/scripting/api.pkg (arbetskopia) @@ -94,16 +94,26 @@ /* Class methods. */ + +/* Player */ int api_methods_player_num_cities @ methods_player_num_cities (Player *pplayer); int api_methods_player_num_units @ methods_player_num_units (Player *pplayer); -bool api_methods_unit_type_has_flag - @ methods_unit_type_has_flag (Unit_Type *punit_type, const char *flag); -bool api_methods_unit_type_has_role - @ methods_unit_type_has_role (Unit_Type *punit_type, const char *role); +/* Government */ +const char *api_methods_government_rule_name + @ methods_government_rule_name (Government *pgovernment); +const char *api_methods_government_translated_name + @ methods_government_translated_name (Government *pgovernment); +/* Nation_Type */ +const char *api_methods_nation_type_rule_name + @ methods_nation_type_rule_name (Nation_Type *pnation); +const char *api_methods_nation_type_translated_name + @ methods_nation_type_translated_name (Nation_Type *pnation); + +/* Building_Type */ bool api_methods_building_type_is_wonder @ methods_building_type_is_wonder (Building_Type *pbuilding); bool api_methods_building_type_is_great_wonder @@ -112,8 +122,33 @@ @ methods_building_type_is_small_wonder (Building_Type *pbuilding); bool api_methods_building_type_is_improvement @ methods_building_type_is_improvement (Building_Type *pbuilding); +const char *api_methods_building_type_rule_name + @ methods_building_type_rule_name (Building_Type *pbuilding); +const char *api_methods_building_type_translated_name + @ methods_building_type_translated_name (Building_Type *pbuilding); +/* Unit_Type */ +bool api_methods_unit_type_has_flag + @ methods_unit_type_has_flag (Unit_Type *punit_type, const char *flag); +bool api_methods_unit_type_has_role + @ methods_unit_type_has_role (Unit_Type *punit_type, const char *role); +const char *api_methods_unit_type_rule_name + @ methods_unit_type_rule_name (Unit_Type *punit_type); +const char *api_methods_unit_type_translated_name + @ methods_unit_type_translated_name (Unit_Type *punit_type); +/* Tech_Type */ +const char *api_methods_tech_type_rule_name + @ methods_tech_type_rule_name (Tech_Type *ptech); +const char *api_methods_tech_type_translated_name + @ methods_tech_type_translated_name (Tech_Type *ptech); + +/* Terrain */ +const char *api_methods_terrain_rule_name + @ methods_terrain_rule_name (Terrain *pterrain); +const char *api_methods_terrain_translated_name + @ methods_terrain_translated_name (Terrain *pterrain); + $[ -- Player methods. function Player:is_human() @@ -133,6 +168,24 @@ return find.city(self.owner, self.homecity_id) end +-- Government methods +function Government:rule_name() + return methods_government_rule_name(self) +end + +function Government:translated_name() + return methods_government_translated_name(self) +end + +-- Nation_Type methods +function Nation_Type:rule_name() + return methods_nation_type_rule_name(self) +end + +function Nation_Type:translated_name() + return methods_nation_type_translated_name(self) +end + -- Building_Type methods. function Building_Type:build_shield_cost()
Re: [Freeciv-Dev] (PR#39450) Make rule names available in the scripting api
URL: http://bugs.freeciv.org/Ticket/Display.html?id=39450 Ulrik Sverdrup wrote: So we would have Unit_Type:rule_name() Unit_Type:name() etc. No, that would be rule_name() and translated_name() It seems a good idea, as it would cache the *_name pointers, but are there high performance issues for a scripted language? Design question: Should both :rule_name() and :name() be available? I'm in favor of only the translated name, I'm not sure I know any uses of the rule name. Presumably for find_*_by_name(), which is always a rule_name! Easier to write them both, and have them in the code as needed, than not have them and need to await the next code release. We've not been very fast at code releases ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
Re: [Freeciv-Dev] (PR#39450) Make rule names available in the scripting api
URL: http://bugs.freeciv.org/Ticket/Display.html?id=39450 Thanks for replying to this, you are the one who knows the related code well. 2007/7/13, William Allen Simpson [EMAIL PROTECTED]: URL: http://bugs.freeciv.org/Ticket/Display.html?id=39450 Ulrik Sverdrup wrote: So we would have Unit_Type:rule_name() Unit_Type:name() etc. No, that would be rule_name() and translated_name() I understand. I just try to think of that others who are not freeciv coders should eventually use the interface, so I thought our consistency standards didn't apply in the same way. I thought: If we use both, one should be :name() to make sure that it is the one you want to use in user messages. If we only make the translated name available, it should be clear that it is not the rule name, so it should be name_translated() Disregarding all that and giving that discussion no weight, we don't do anything wrong by sticking to the name conventions used in the rest of the code. It seems a good idea, as it would cache the *_name pointers, but are there high performance issues for a scripted language? No. I only thought it might be an abstraction thing; as you said during the transition you wished that more code used the accessor functions. Design question: Should both :rule_name() and :name() be available? I'm in favor of only the translated name, I'm not sure I know any uses of the rule name. Presumably for find_*_by_name(), which is always a rule_name! Easier to write them both, and have them in the code as needed, than not have them and need to await the next code release. We've not been very fast at code releases Yeah, but find by name only works on known rule names -- these accessors are only there for when you get an object of unknown type and want to (for example) print a message about it-- if you have an unknown 'unit' do find.unit_type(unit.utype:name()) you could just as well use unit:utype() ; and the same for other cases. But on the other hand I agree that it is easy to write them both. Much of the api generation for us is just many, many easily written short pieces of code and this is just more of that. ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
Re: [Freeciv-Dev] (PR#39450) Make rule names available in the scripting api
URL: http://bugs.freeciv.org/Ticket/Display.html?id=39450 Ulrik Sverdrup wrote: 2007/7/13, William Allen Simpson [EMAIL PROTECTED]: No, that would be rule_name() and translated_name() I understand. I just try to think of that others who are not freeciv coders should eventually use the interface, so I thought our consistency standards didn't apply in the same way. 1) Non-C coders need even longer and more descriptive functions, as they are less likely to read the underlying C code itself. 2) Consistency is even more important. We'll have to debug their code. I thought: If we use both, one should be :name() to make sure that it is the one you want to use in user messages. Hell, no! The lack of clear distinction was what caused me to waste nearly all of my free time for a month to fix this crap. Particularly irksome that prior coders had identified the problem, and left comment blocks about it, but left it for somebody else If we only make the translated name available, it should be clear that it is not the rule name, so it should be name_translated() No, it should be translated_name() Consistency, always consistency. You don't want to have to grep half a dozen possible function names, even in this small project. That gets rapidly tiresome, and you miss too many. No. I only thought it might be an abstraction thing; as you said during the transition you wished that more code used the accessor functions. Damned straight! Some parts of this code are nicely done. Others are/were a mess, and difficult to fix because folks didn't use the *existing* accessor functions. Abstraction was developed by computer scientists for a reason. It's not just an undergraduate exercise. But on the other hand I agree that it is easy to write them both. Much of the api generation for us is just many, many easily written short pieces of code and this is just more of that. Yes. ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
