const methods in the content public interface

[Lucas Gadani]

The current recommendation for content/public api is to avoid const interfaces on the interfaces. In particular, https://www.chromium.org/developers/content-module/content-api lists:

"don't add the const identifier to interfaces. For interfaces implemented by the embedder, we can't make assumptions about what the embedder needs to implement it. For interfaces implemented by content, the implementation details doesn't have to be exposed."

I can see why this makes sense for delegate interfaces implemented by the embedder, but what about interfaces implemented in content? What's the advantage here?

In particular, we haven't been enforcing this rule. Looking at content::WebContents, I counted 54 const methods. The main problem of having only non-const methods on the interface is that they aren't callable by internal content const methods. The alternatives of const_cast'ing the objects or removing constness on the internal interface seems worse to me than allowing const on the interfaces implemented by content.

I propose that we should modify the content API rules to allow const interfaces on objects implemented by content, but not on the interfaces implemented by the embedder. Thoughts?

[John Abd-El-Malek]

On Tue, Oct 30, 2018 at 10:15 AM Lucas Gadani <l...@chromium.org> wrote:

The current recommendation for content/public api is to avoid const interfaces on the interfaces. In particular, https://www.chromium.org/developers/content-module/content-api lists:

"don't add the const identifier to interfaces. For interfaces implemented by the embedder, we can't make assumptions about what the embedder needs to implement it. For interfaces implemented by content, the implementation details doesn't have to be exposed."

I can see why this makes sense for delegate interfaces implemented by the embedder, but what about interfaces implemented in content? What's the advantage here?

The reason this was done was because it came up that changes to a content method's implementation necessitated removing the const, which ended up having to change a bunch of code in src/chrome so that the object passed in isn't const. We shouldn't have to change embedders because of a change in how content works.

 

In particular, we haven't been enforcing this rule. Looking at content::WebContents, I counted 54 const methods. The main problem of having only non-const methods on the interface is that they aren't callable by internal content const methods.

We can make these non-const then..

 

The alternatives of const_cast'ing the objects or removing constness on the internal interface seems worse to me than allowing const on the interfaces implemented by content.

I propose that we should modify the content API rules to allow const interfaces on objects implemented by content, but not on the interfaces implemented by the embedder. Thoughts?

--
You received this message because you are subscribed to the Google Groups "Chromium Embedders" group.
To unsubscribe from this group and stop receiving emails from it, send an email to embedder-dev...@chromium.org.
To post to this group, send email to embedd...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/embedder-dev/CAEgCuoEhyvb3XFF1OLY0xBBtCgRhMPOH_-cXithSVLyBOkXjCw%40mail.gmail.com.

[Lucas Gadani]

On Tue, Nov 6, 2018 at 11:30 AM John Abd-El-Malek <j...@chromium.org> wrote:

On Tue, Oct 30, 2018 at 10:15 AM Lucas Gadani <l...@chromium.org> wrote:

The current recommendation for content/public api is to avoid const interfaces on the interfaces. In particular, https://www.chromium.org/developers/content-module/content-api lists:

"don't add the const identifier to interfaces. For interfaces implemented by the embedder, we can't make assumptions about what the embedder needs to implement it. For interfaces implemented by content, the implementation details doesn't have to be exposed."

I can see why this makes sense for delegate interfaces implemented by the embedder, but what about interfaces implemented in content? What's the advantage here?

The reason this was done was because it came up that changes to a content method's implementation necessitated removing the const, which ended up having to change a bunch of code in src/chrome so that the object passed in isn't const. We shouldn't have to change embedders because of a change in how content works.

That seems reasonable.

In particular, we haven't been enforcing this rule. Looking at content::WebContents, I counted 54 const methods. The main problem of having only non-const methods on the interface is that they aren't callable by internal content const methods.

We can make these non-const then..

I'm ok with the rule as long as we are consistent. If no one else objects to this, I'll start sending patches to fix the current behavior and after the current state is fixed, I'll add a presubmit check to enforce the non-constness of the public API.