<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
> > 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