[webkit-dev] converting by constructor
Hi, I have a basic question. What has been WebKit's stance on the use of the explicit keyword (for higher-level objects in particular)? Do we prefer the looser API's that conversion by constructor affords, or do we more often discourage relying on conversion by constructor? For comparison, the Google C++ style guide says the explicit keyword should almost always be used. Note that I'm not suggesting that this be added to our style guide. Thanks, --Chris ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] converting by constructor
My understanding is that we almost always use the explicit keyword unless we explicitly want implicit construction. For example, AtomicString has a non-explicit constructor that takes a String on purpose (or at least controlled by NO_IMPLICIT_ATOMICSTRING). Adam On Mon, May 17, 2010 at 12:39 PM, Chris Jerdonek cjerdo...@webkit.org wrote: Hi, I have a basic question. What has been WebKit's stance on the use of the explicit keyword (for higher-level objects in particular)? Do we prefer the looser API's that conversion by constructor affords, or do we more often discourage relying on conversion by constructor? For comparison, the Google C++ style guide says the explicit keyword should almost always be used. Note that I'm not suggesting that this be added to our style guide. Thanks, --Chris ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] converting by constructor
I think the Google guideline is pretty close to what a WebKit guideline would be. The explicit keyword should almost always be used when a constructor is creating an object and not just converting type from one to another. Leaving out the explicit keyword should be thought of as equivalent to defining a conversion operator, albeit working in the opposite direction. The AtomicString example Adam Barth cited is a problematic one. The cost of making an AtomicString from a String is high enough that having the conversion be implicit might be a mistake! But it was intentional I think the best way for us to clarify our guideline for this would be to discuss a few individual cases where we have a non-explicit constructor. We can talk about why they are not explicit and see if we find they are just bugs or show a principle at work. -- Darin ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] converting by constructor
On Mon, May 17, 2010 at 3:11 PM, Darin Adler da...@apple.com wrote: I think the best way for us to clarify our guideline for this would be to discuss a few individual cases where we have a non-explicit constructor. We can talk about why they are not explicit and see if we find they are just bugs or show a principle at work. I wasn't intending to create a formal guideline, but one example I encountered recently is ResourceRequest, which has String and KURL single-parameter constructors without the explicit keyword. The FrameLoader class has about 25 methods that accept a ResourceRequest (e.g. various load methods), so all of these also accept a String and KURL. This makes it harder to know the right way these methods should be getting called. This also makes it harder to refactor. Call sites seem to use all three variations. The class also has other load-like methods that accept a String url, and others that accept a KURL url. --Chris ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] converting by constructor
On Mon, May 17, 2010 at 5:28 PM, Chris Jerdonek cjerdo...@webkit.org wrote: On Mon, May 17, 2010 at 3:11 PM, Darin Adler da...@apple.com wrote: I think the best way for us to clarify our guideline for this would be to discuss a few individual cases where we have a non-explicit constructor. We can talk about why they are not explicit and see if we find they are just bugs or show a principle at work. I wasn't intending to create a formal guideline, but one example I encountered recently is ResourceRequest, which has String and KURL single-parameter constructors without the explicit keyword. The FrameLoader class has about 25 methods that accept a ResourceRequest (e.g. various load methods), so all of these also accept a String and KURL. This makes it harder to know the right way these methods should be getting called. This also makes it harder to refactor. Call sites seem to use all three variations. Ouch. That sounds like a bug. :) The class also has other load-like methods that accept a String url, and others that accept a KURL url. Yeah, the whole String/KURL representation of a url issue is something we'd like to clean up at some point too. One of the considerations here is that KURL takes more memory than String to represent a URL. We'd like to measure and see how big an effect that is. One thing we could do in the intermediate term is use the type URLString for URLs that we store as Strings. This change wouldn't affect the compiled code, but it would help us keep track of what's going on better and pave the way for further changes in the future. I wrote a patch that started to do this, but the discussion got a bit sidetracked into the larger questions surrounding how to represent URLs: https://bugs.webkit.org/show_bug.cgi?id=36794 Adam ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] converting by constructor
On May 17, 2010, at 12:39 PM, Chris Jerdonek wrote: Hi, I have a basic question. What has been WebKit's stance on the use of the explicit keyword (for higher-level objects in particular)? Do we prefer the looser API's that conversion by constructor affords, or do we more often discourage relying on conversion by constructor? For comparison, the Google C++ style guide says the explicit keyword should almost always be used. Note that I'm not suggesting that this be added to our style guide. We like to use implicit conversion where it makes sense. We only use the explicit keyword to prevent specifically undesired implicit conversions. As an example, the implicit conversions between String and AtomicString are very useful. They let the bindings generator write code from IDL without having to know whether the underlying C++ method takes a String or an AtomicString. An example of a bad implicit conversion would be the Vector constructor that takes just a size_t. We don't want numbers passed as parameters to magically turn into Vectors, not only is that confusing but it would lead to ambiguous overloads. So we mark it explicit. Regards, Maciej ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
