Add the const modififier to HTMLLabelElement::correspondingControl
Created attachment 52594 [details] Patch
Comment on attachment 52594 [details] Patch Generally speaking, it's not all that helpful to have const in the DOM tree. You can't traverse the tree without losing the const modifier anyway, so it's not normally a useful distinction, although we do have const here and there on DOM objects. Similarly, the notion of a const pointer to a DOM element doesn't exist in JavaScript or even in Objective-C. Is it really important to be able to do this operation on a const HTMLLabelElement*? When would one of those even arise?
(In reply to comment #2) > (From update of attachment 52594 [details]) > Generally speaking, it's not all that helpful to have const in the DOM tree. > You can't traverse the tree without losing the const modifier anyway, so it's > not normally a useful distinction, although we do have const here and there on > DOM objects. Similarly, the notion of a const pointer to a DOM element doesn't > exist in JavaScript or even in Objective-C. > > Is it really important to be able to do this operation on a const > HTMLLabelElement*? When would one of those even arise? As a matter of style, it's best to use const objects when possible. In Chrome AutoFill, we have label parsing code that traverses the DOM in an HTMLFormElement, pulling out the labels. In the case where a form has HTMLLabelElements, we just need to read the innerText() from the HTMLLabelElement objects. Since the parsing is a read-only operation, there's really no reason not to have const objects.
Comment on attachment 52594 [details] Patch Marking r- for now. We can probably do this if there's a more compelling reason than style though.
Closing.
(In reply to comment #3) > As a matter of style, it's best to use const objects when possible. I believe this greatly overstates the matter. I think const is a quite-useful concept to make code clearer and prevent certain classes of programming mistakes, but in this case I don't agree. Calling innerText has many side effects, so it's not necessarily a classic example of a "const" operation. It can trigger a lot of work, including network loading.
(In reply to comment #6) > (In reply to comment #3) > > As a matter of style, it's best to use const objects when possible. > > I believe this greatly overstates the matter. > > I think const is a quite-useful concept to make code clearer and prevent > certain classes of programming mistakes, but in this case I don't agree. > > Calling innerText has many side effects, so it's not necessarily a classic > example of a "const" operation. It can trigger a lot of work, including network > loading. Ok, thanks for the insights Darin. I'm going to re-close this bug.