Patrick Parker <[EMAIL PROTECTED]>:
> Not quite true... radius upconversion, for example violates NTC.
Aarggh. The one transformation I didn't write.
Please fix the transformation to have NTC. Otherwise I'll have to make
wmllint throw a warning every time it's done, or (see below) disable
it entirely. The warning would become painful rather quickly as usage
of the feature increases.
> >1. We have to be fairly careful about reusing resource file names.
>
> explain?
Suppose the name mappings associated with two different version transitions
included both
1.4.1: foo.png -> bar.png
1.4.6: foo.png -> qux.png
This could happen if a developer reused the resource file name foo.png
not knowing it already had a use before 1.4.1, then *after* his reuse
decided to change it.
Suddenly what foo.png got transformed to would depend on --oldversion,
which would be OK until somebody got the argument wrong. Then you'd have
a bug that might be very tough to spot.
> >2. We have to be equally careful about reusing WML tag names with
> >different enclosed or enclosing tags.
>
> too restrictive IMO
Not too restrictive, in *my* opinion. We could go down a long rathole
about this, but it's essentially a value and priority judgment. So
I'm not going to argue the point, I'm just going to say what I'll do.
I think maintainability and preserving NTC is important enough to
justify bending WML a little. I also want to preserve the possibility
of embedding it in the campaign server and having it run completely
out of sight of the invoking user.
Therefore: wearing my wmllint maintainer hat, I will *not* write a
transformation that violates NTC. Nor will I allow a transformation
that does so to remain part of wmllint's behavior. In fact, it is my
intention to add code that checks for NTC violations and aborts with an
error if it finds one.
You can believe my priorities are wrong, but as long as I'm maintaining
wmllint that will be the rule.
--
<a href="http://www.catb.org/~esr/";>Eric S. Raymond</a>
_______________________________________________
Wesnoth-dev mailing list
Wesnoth-dev@gna.org
https://mail.gna.org/listinfo/wesnoth-dev
