Add the const modififier to HTMLLabelElement::correspondingControl

• Component: DOM
• Status: RESOLVED WONTFIX

[James Hawkins]

Add the const modififier to HTMLLabelElement::correspondingControl

[James Hawkins]

Created attachment 52594 [details]
Patch

[Darin Adler]

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?

[James Hawkins]

(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.

[Adam Barth]

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.

[James Hawkins]

Closing.

[Darin Adler]

(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.

[James Hawkins]

(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.