[Webkit-unassigned] [Bug 132269] Document.contentType implementation

bugzilla-daemon at webkit.org bugzilla-daemon at webkit.org
Thu Dec 11 09:32:29 PST 2014


https://bugs.webkit.org/show_bug.cgi?id=132269

--- Comment #38 from Darin Adler <darin at apple.com> ---
Comment on attachment 242800
  --> https://bugs.webkit.org/attachment.cgi?id=242800
Patch v7

View in context: https://bugs.webkit.org/attachment.cgi?id=242800&action=review

>>> Source/WebCore/loader/DocumentLoader.h:121
>>>          WEBCORE_EXPORT void setResponseMIMEType(const String&);
>> 
>> Seems strange to put the new "mimeType" function between responseMIMEType and setResponseMIMEType, which were previously right next to each other. Can we find a better place for this?
>> 
>> Also, it’s confusing that we have a function named responseMIMEType and a second function named mimeType. Maybe we need a longer name for the new function.
> 
> I replaced it, now it's after the setResponseMIMEType function. Could you possibly suggest a better name for this simple getter?

I have three thoughts about the name:

1) In the context of this class, the key issue is that there are multiple of these types. There’s the type from the response and the type that the loader has determined we should use for the document. Since both exist, neither function should be named just “type”, “content type” or “MIME type” and lack an additional clarifying modifier. So maybe one is the responseMIMEType and the other is the computedContentType or the currentContentType. Think of words that would distinguish the two. One property of the latter type is that it changes as we parse more of the document, perhaps? I don’t really know and it’s worth a little research.

2) Another way to resolve the ambiguity from (1) above would be to remove some of the DocumentLoader functions like requestURL and responseURL and responseMIMEType and instead have callers get the request and response directly and get the information from there. If that was true, then I’d be comfortable naming the function contentType since there would not be a responseMIMEType function in the same class. This would also probably improve the interface to the document loader class by cutting down the number of separate functions.

3) I personally can’t stand using the acronym MIME so often. I’d prefer to call these things content type rather than MIME type. But that’s not specific to this function. And perhaps there are other “types of types” that this would make confusing.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-unassigned/attachments/20141211/d16113fa/attachment-0002.html>


More information about the webkit-unassigned mailing list