https://bz.apache.org/bugzilla/show_bug.cgi?id=66541
--- Comment #6 from Tom Whitmore <tom.whitm...@lyniate.com> --- Thanks. The "wrapped one" is the outer one; I use wrapped & underlying as a frequent terminology, it works well & is clear semantically. > I'm not sure wrappedURL is the best terminology either since it is the > original > resource URL that is wrapped. * I think this objection is not logically correct, it's confusing the subject with the verb/ transformation. * The fact that you apply an operation (wrapping) to an input to produce a result, does not mean that you should describe or identify the input with the operation (wrapping). * Using a verb to select inputs is misusing a linguistic shortcut from selectivity; used where there is no ambiguity about which is input & output but where there is a need to select which of many inputs is used. * Here however, there is only one input, there is ambiguity between inputs and outputs, and the question of selectivity (which URL is the handler being called with?) applies only in the domain of outputs. * The 'wrappedURL' is wrapped with the new URLStreamHandler. The underlying 'resourceURL' is not itself wrapped. It is prima facie confusing to refer the resourceURL as itself being wrapped, since it itself is not. Better might be to say "We wrap the underlying Resource URL with a Cache-aware URL Handler, to produce the Wrapped URL". This clearly distinguishes the input (the Resource URL), the operation (wrapping) and the result (the Wrapped URL). Language can sometimes be tricky. I think it's worth clearly distinguishing between _descriptive terminology_, which should be preferred, and _implicit selection_ which is sometimes useful but can -- as in this case -- also lead to unnecessary confusion. Thanks Mark. I hope this helps! -- You are receiving this mail because: You are the assignee for the bug. --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
