chromatic wrote:
On Sunday 13 April 2008 10:41:04 Michael G Schwern wrote:
Remember, the producer and the displayer of the non-reserved keys are both
under local user control. They choose the custom keys and they choose what
they need and can handle.
That sort of eliminates the upgrading problem, doesn't it?
How's that?
Remind me again why TAP needs to reserve a whole range of keywords or invent
disambiguation schemes if there's no upgrading problem?
Same reason we have trouble adding new keywords to Perl 5, a user might have
defined a key to mean one thing and suddenly we're saying it means something
else. Clash.
(Apologies for the hokey example, I'm not feeling creative)
Let's say Test::Builder spits out "file", "line" and "name" keys automatically.
User written producer on top of Test::Builder adds their own "flavor" key
meaning ice cream flavor.
User extended displayer displays appropriate pictures of ice cream based on
the "flavor".
TAP decides "flavor" should be all about quarks. Strange, top, bottom, etc...
Test::Builder starts emitting "flavor" keys automatically.
User written producer's keys and Test::Builder now clash. User written
producer overrides (Test::Builder's choice, but maybe in another system it's
the other way around) losing the Test::Builder supplied data.
TAP displayer's interpretation of "flavor" now clashes with TAP's official
meaning. Tests written using other TAP producers use the official "flavor"
meaning and confuse the customized TAP displayer. Existing, uncustomized TAP
displayers interpret their use of "flavor" incorrectly.
User now has to decide between being non-standard and incompatible with other
standardized TAP components or renaming all their uses of "flavor" to be
"ice_cream_flavor".
--
44. I am not the atheist chaplain.
-- The 213 Things Skippy Is No Longer Allowed To Do In The U.S. Army
http://skippyslist.com/list/
