Due to my typing difficulty ATM, I can't respond as verbosely as I'd like,
but I do want to weigh in on the shape of WML evolution, since it is an area
of great interest and concern.
>There are still good use cases for version numbering. Sometimes it's
>not possible to use a strategy like PNG's with neatly self-describing
>content. *But WML is not one of these cases*. WML syntax, like PNG's
>packet structure, guarantees that a WML file will be parseable even if
>it has unknown tags and/or attributes in it.
WML version is not self-evident from content, nor should we force it to be.
WML is a work in progress. While the basic parsing rules and preprocessing
rules haven't changed much over time, the conclusion that it is neatly
self-describing does not follow.
>A version number would just be a distraction. It would violate what
>database designers call the SPOT ("Single Point of Truth") rule,
>sometimes known in coding circles as the DRY (Don't Repeat Yourself)
>rule.
Here is where I agree with you. After reading your argument, I am convinced
that a version stamp would violate SPOT. Specifying version in countless
files would contradict the version that can be specified on the commandline,
which --oldversion. After weighing all the possibilities, requiring wmllint
users to specify which version they are converting from seems the safest and
most logical choice.
>I wrote wmllint, so I know that the set of transformations in it has
>the following property: *no transformation ever produces on output
>a text pattern that is any of the other transformations' inputs*.
>I'll call this the "no-transitive-chains" propety, or NTC for short.
Not quite true... radius upconversion, for example violates NTC. As will
doubtless many other future transformations, unless we go the 'warn' route,
which I think isn't that useful. Remember, WML is a work in progress. Some
bad design choices have been made in the past, and we would like to
eliminate those when possible and when relatively painless.
>Among other things, this means (in
>principle) that you could embed wmllint in the campaigns server and
>have it automatically lift submitted UMC.
Automatic content checking is a good idea, but automatic version guessing +
content checking may prove too restrictive.
>Adaptive code that automatically preserves
>the invariants you care about is better than switches that can
>break things.
>
There are already safeguards against that (diff and .bak files), and any
user smart enough to know how to run the tool in the first place is smart
enough to know what version number he is converting from.
I agree that switches for each individual transformation (as proposed by
zookeeper) are a bad idea (due to information overload).
>1. We have to be fairly careful about reusing resource file names.
explain?
>2. We have to be equally careful about reusing WML tag names with
>different enclosed or enclosing tags.
too restrictive IMO
>For example, the syntax transformation boucman has requested in
>FR #9952 could violate NTC by the way it changes the use of the
>[animation] tag. The new block will probably have to be called
>[effect_anim] or something else, otherwise I think this transformation
>could trigger on its own output.
Changing WML tags for this reason alone is bad, very bad, and I am adamantly
opposed to it.
I'm coming from the perspective of someone who was a WML author for a long
time before being a developer.
Memorization of WML tags represents a sizable human investment, and wmllint
is made to help humans.
Also, WML tags and keys and structures are designed to be as easy and
intuitive as possible.
By changing them, either you must assert that the original design choice was
flawed (in which case, the degree of flaw must be carefully weighed), or you
are admittedly degrading it.
--
Sapient
_________________________________________________________________
Express yourself instantly with MSN Messenger! Download today it's FREE!
http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/
_______________________________________________
Wesnoth-dev mailing list
[email protected]
https://mail.gna.org/listinfo/wesnoth-dev
