Chris, Thank you for the real word experience report. I had assumed (because everyone else told me) that importing qualified would be much, much better than prefixing. I had thought that in your case since you are big on model separation that you would have liked having a separate file for each model to separate out all your model related code with. As a counter point, in all of my (MVC) web application projects, we do have a separate file for each model, and we like this approach. Each file usually contains a lot of "business logic" related to the model- the only relatively empty model files are ones that really represent embedded data. When I use MongoDB (which actually supports embedded data instead of forcing you to create a separate table), I will actually place the embedded models in the same file as the model which includes them.<div>
<br><div>After my blog post complaining about records, I had a few people telling me that I can just use existing polymorphism to avoid the name-spacing issue. I collected the approaches here: <a href="http://www.yesodweb.com/wiki/record-hacks">http://www.yesodweb.com/wiki/record-hacks</a></div>
<div>I didn't think any of those telling me what i should do had actually tried to do this themselves, particularly at any kind of larger scale. I am interested to see if anyone has experience trying this approach, or if you have considered it.</div>
<div><div><div><br></div><div><div class="gmail_quote">On Thu, Sep 15, 2011 at 3:00 AM, Christopher Done <span dir="ltr"><<a href="mailto:chrisdone@googlemail.com">chrisdone@googlemail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
I added my evaluation of the module-based approach to existing<br>
records, but on second thoughts it's maybe inappropriate, so I'll post<br>
it here. I saw that some people commented on the reddit discussion<br>
that the solution is to put your types in separate modules but it<br>
doesn't seem that anyone has tried to do this on a large scale. I<br>
tried it (and some other record paradigms including Has), but I don't<br>
think it scales. Here's why…<br>
<br>
Suppose I have 112 hand-crafted data types in my<br>
project (e.g. see attachment 51369.txt[1]), this creates a lot of<br>
conflicts in field names and constructor names. For example:<br>
<br>
{{{<br>
data Comment = Comment {<br>
commentId :: CommentId<br>
, commentContent :: Content<br>
, commentReviewId :: ReviewId<br>
, commentSubmissionId :: SubmissionId<br>
, commentConferenceId :: ConferenceId<br>
, commentDate :: ISODate<br>
, commentReviewerNumber :: Int<br>
} deriving (Show)<br>
}}}<br>
<br>
This is a real type in my project. It has fields like “id”, “content”,<br>
“reviewId”, “submissionId”, “date”. There are seven other data types<br>
that have a field name “submissionId”. There are 15 with<br>
“conferenceId”. There are 7 with “content”. And so on. This is just to<br>
demonstrate that field clashes ''do'' occur ''a lot'' in a nontrivial<br>
project.<br>
<br>
It also demonstrates that if you propose to put each of these 112 types<br>
into a separate module, you are having a laugh. I tried this around<br>
the 20 type mark and it was, apart from being very slow at compiling,<br>
''very'' tedious to work with. Creating and editing these modules was a<br>
distracting and pointless chore.<br>
<br>
It ''also'' demonstrated, to me, that qualified imports are horrible<br>
when used on a large scale. It happened all the time, that'd I'd<br>
import, say, 10 different data types all qualified. Typing map<br>
(Foo.id . BarMu.thisField) and foo Bar.Zot{x=1,y=2} becomes tedious<br>
and distracting, especially having to add every type module when I<br>
want to use a type. And when records use other types in other modules,<br>
you have ''a lot'' of redundancy. With the prefixing paradigm I'd write<br>
fooId and barMuThisField, which is about as tedious but there is at<br>
least less . confusion and no need to make a load of modules and<br>
import lines. Perhaps local modules would solve half of this<br>
problem. Still have to write “Bar.mu bar” rather than “mu bar”, but<br>
it'd be an improvement.<br>
<br>
I also have 21 Enum types which often conflict. I end up having to<br>
include the name of the type in the constructor, or rewording it<br>
awkwardly. I guess I should put these all in separate modules and<br>
import qualified,<br>
too. Tedious, though. At least in this case languages like C# and<br>
Java also require that you type EnumName.EnumValue, so c‘est la vie.<br>
<br>
[1]: <a href="http://hackage.haskell.org/trac/ghc/attachment/wiki/Records/51369.txt" target="_blank">http://hackage.haskell.org/trac/ghc/attachment/wiki/Records/51369.txt</a><br>
<br>
_______________________________________________<br>
Glasgow-haskell-users mailing list<br>
<a href="mailto:Glasgow-haskell-users@haskell.org">Glasgow-haskell-users@haskell.org</a><br>
<a href="http://www.haskell.org/mailman/listinfo/glasgow-haskell-users" target="_blank">http://www.haskell.org/mailman/listinfo/glasgow-haskell-users</a><br>
</blockquote></div><br></div></div></div></div>