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.
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: http://www.yesodweb.com/wiki/record-hacks
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.
On Thu, Sep 15, 2011 at 3:00 AM, Christopher Done
I added my evaluation of the module-based approach to existing records, but on second thoughts it's maybe inappropriate, so I'll post it here. I saw that some people commented on the reddit discussion that the solution is to put your types in separate modules but it doesn't seem that anyone has tried to do this on a large scale. I tried it (and some other record paradigms including Has), but I don't think it scales. Here's why…
Suppose I have 112 hand-crafted data types in my project (e.g. see attachment 51369.txt[1]), this creates a lot of conflicts in field names and constructor names. For example:
{{{ data Comment = Comment { commentId :: CommentId , commentContent :: Content , commentReviewId :: ReviewId , commentSubmissionId :: SubmissionId , commentConferenceId :: ConferenceId , commentDate :: ISODate , commentReviewerNumber :: Int } deriving (Show) }}}
This is a real type in my project. It has fields like “id”, “content”, “reviewId”, “submissionId”, “date”. There are seven other data types that have a field name “submissionId”. There are 15 with “conferenceId”. There are 7 with “content”. And so on. This is just to demonstrate that field clashes ''do'' occur ''a lot'' in a nontrivial project.
It also demonstrates that if you propose to put each of these 112 types into a separate module, you are having a laugh. I tried this around the 20 type mark and it was, apart from being very slow at compiling, ''very'' tedious to work with. Creating and editing these modules was a distracting and pointless chore.
It ''also'' demonstrated, to me, that qualified imports are horrible when used on a large scale. It happened all the time, that'd I'd import, say, 10 different data types all qualified. Typing map (Foo.id . BarMu.thisField) and foo Bar.Zot{x=1,y=2} becomes tedious and distracting, especially having to add every type module when I want to use a type. And when records use other types in other modules, you have ''a lot'' of redundancy. With the prefixing paradigm I'd write fooId and barMuThisField, which is about as tedious but there is at least less . confusion and no need to make a load of modules and import lines. Perhaps local modules would solve half of this problem. Still have to write “Bar.mu bar” rather than “mu bar”, but it'd be an improvement.
I also have 21 Enum types which often conflict. I end up having to include the name of the type in the constructor, or rewording it awkwardly. I guess I should put these all in separate modules and import qualified, too. Tedious, though. At least in this case languages like C# and Java also require that you type EnumName.EnumValue, so c‘est la vie.
[1]: http://hackage.haskell.org/trac/ghc/attachment/wiki/Records/51369.txt
_______________________________________________ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users