<br><br><div class="gmail_quote">On Thu, Apr 22, 2010 at 9:42 AM, Jeremy Shaw <span dir="ltr"><<a href="mailto:jeremy@n-heptane.com">jeremy@n-heptane.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div style="word-wrap:break-word">Hello,<div><br></div><div>I am not especially excited about it. The fact that some mime-types are hard coded, and others are not is an annoying 'inconsistency'. </div><div><br></div>
<div>There is no way to extend the list of supported types in user apps. And typeByExt has a rather limited set up extensions, declaring everything else to be application/octet-stream.</div><div><br></div><div>The use of a type for the mime-types implies that you want to be pattern matching on the constructors in your code ? Can you give a use case for that ?</div>
<div><br></div><div><br></div></div></blockquote><div>I wouldn't say that type implies pattern matching. I think the type makes code much clearer. For example, in Haskell I have:</div><div><br></div><div>type ChooseRep = [ContentType] -> IO (ContentType, Content)</div>
<div><br></div><div>I find that to be *much* clearer than</div><div><br></div><div>type ChooseRep = [String] -> IO (String, Content)</div><div><br></div><div>You could argue that I should just be using a type instead of a datatype, but that's an old debate between convenience and compiler type-safety. You could also argue that this should just be</div>
<div><br></div><div>newtype ContentType = ContentType String</div><div><br></div><div>I find three advantages for the current method. First, in theory passing around a TypeHtml constructor takes less memory than a ContentType "text/html; charset=utf-8", but I could be missing something about optimizations here. Second, it's just a lot more convenient to write in the first place. The alternative to having TypeHtml etc constructors would be:</div>
<div><br></div><div>typeHtml :: ContentType</div><div>typeHtml = ContentType "text/html; charset=utf-8"</div><div><br></div><div>Plus adding each function to the export list is just more tedious. Finally, I find the code *looks* better using a constructor than a function, eg</div>
<div><br></div><div>chooseRep [TypeHtml, TypeJson]</div><div><br></div><div>versus</div><div><br></div><div>chooseRep [typeHtml, typeJson]</div><div><br></div><div>though that's just a matter of taste.</div><div><br></div>
<div>I'm also not too concerned about the inconsistency, though I see where you're coming from. One of the advantages I'd see of opening this into a standalone package is that in theory the whole community could keep adding mimetypes until this is very comprehensive.</div>
<div><br></div><div>I find your argument to be more apropos to the typeByExt function, since that *is* a case where users would want to both extend and override library defaults. I see two options here:</div><div><br></div>
<div>* Change typeByExt to have return type "Maybe ContentType", and then users won't need to worry about the TypeOctet appearing all over the place. They can choose whatever default they want. If they want to extend or override, they just need to write their own function to be called before typeByExt.</div>
<div>* Don't provide a function at all; instead, provide a Map (or trie) with a number of built-in extension -> mimetype mappings. Users could then just do a lookup, as well as make changes to that Map.</div><div><br>
</div><div>Michael</div></div>