<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 [email protected] https://mail.gna.org/listinfo/freeciv-dev
