On Fri, August 11, 2006 4:30 am, Zeev Suraski wrote: > The solution I propose is to create internal functions that will set > 'virtual' filenames and line ranges, that will be saved in some sort > of a translation table, of real filename + line range to virtual > filename + lineno. The error callback can be made smarter to search > in the translation table, and in case of a match, report the virtual > filename:linenumber in addition to the real ones.
This would be a lot more appealing if it also always referenced the original filename and line number as well: Error in: masked_file_name at line masked_line (fka real_file_name at line real_line) That way, any confusion arising from bogus translation tables or thinkos can be traced back to the One True Source. Because, honestly, most of the time I encounter a problem in this sort of thing, the confusion caused by the obfuscated reporting mechanism is worse than the orginal problem. So at least give me some chance of sorting out the messes this will create. :-) You'll also need to consider an interesting "What If"... Package A adds a translation from file X line A to file Y line B. Package B adds a translation from file Y line B to file Z line C. Package C adds a translation from file X line A to file Q line E. As you can see, depending on the order of translations, and the interpretation of that ordering, you either have translations that will suddenly not work because of adding a new package, or you have a dominoe effect of an infinite number of translations, possibly even leading to a recursive loop, or one translation is knocked out by a new one, or... Whatever you expect to happen with such a scenario, will need to be clear, simple and concisely defined, I should think. -- Like Music? http://l-i-e.com/artists.htm -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
