I should be clear that in my counter point I am using Ruby, not Haskell on those projects. In Ruby one can use a string for the name of a class (which will be evaluated later) and other general dynamic typing tricks to avoid cyclical dependencies.<div>
<br></div><div>I have worked on one large Yesod project. I felt they were creating artificially shortened field names in some cases (that I found difficult to understand/remember) to try and ease the pain of large prefixed record selectors. However, Yesod does create all the records with prefixes in one module/file- so all the types are in there. They create a new model file for each model (conceptually, but not for a model representing simple embedded data). The model file can import all the record types.</div>
<div><br></div><div>Personally I would prefer to define my type in the model file so I can quickly see my type with the related code if it were possible, but it seems that it isn't.<br><div><br><div class="gmail_quote">
On Thu, Sep 15, 2011 at 8:15 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;">
2011/9/15 Greg Weber <<a href="mailto:greg@gregweber.info">greg@gregweber.info</a>>:<br>
<div class="im">> Chris, Thank you for the real word experience report. I had assumed (because<br>
> everyone else told me) that importing qualified would be much, much better<br>
> than prefixing. I had thought that in your case since you are big on model<br>
> separation that you would have liked having a separate file for each model<br>
> to separate out all your model related code with. As a counter point, in all<br>
> of my (MVC) web application projects, we do have a separate file for each<br>
> model, and we like this approach. Each file usually contains a lot of<br>
> "business logic" related to the model- the only relatively empty model files<br>
> are ones that really represent embedded data. When I use MongoDB (which<br>
> actually supports embedded data instead of forcing you to create a separate<br>
> table), I will actually place the embedded models in the same file as the<br>
> model which includes them.<br>
<br>
</div>Ah, this is because my approach to types is to put them in a<br>
ProjectName.Types.X module. I /do/ have separate modules for all my<br>
models, e.g.<br>
<br>
$ ls Confy/Model/*.hs<br>
Confy/Model/Actions.hs Confy/Model/Driver.hs<br>
Confy/Model/Manuscript.hs Confy/Model/Proceedings.hs<br>
Confy/Model/SubmissionAuthor.hs Confy/Model/Token.hs<br>
Confy/Model/Activity.hs Confy/Model/Fields.hs<br>
Confy/Model/Message.hs Confy/Model/ReviewComment.hs<br>
Confy/Model/Submission.hs Confy/Model/Track.hs<br>
Confy/Model/Author.hs Confy/Model/FormField.hs<br>
Confy/Model/Papertype.hs Confy/Model/ReviewerPreference.hs<br>
Confy/Model/Tables.hs Confy/Model/User.hs<br>
Confy/Model/Conference.hs Confy/Model/Form.hs<br>
Confy/Model/Participant.hs Confy/Model/Review.hs<br>
Confy/Model/Template.hs Confy/Model/UserMeta.hs<br>
Confy/Model/Deadline.hs Confy/Model/LogEntry.hs<br>
Confy/Model/Period.hs Confy/Model/Role.hs Confy/Model/TH.hs<br>
Confy/Model/Utils.hs<br>
<br>
I have my HaskellDB types and then I have my normal Haskell types<br>
which contain different fields to the database model.<br>
<br>
But to put the /type/ in the model file itself causes cyclic import<br>
problems when I have to start caring about what imports what and then<br>
having modules that just contain types, etc. I find this to be quite<br>
laborious, I did it at first but it became a hindrance to development<br>
practice for me. Have you not found that you have this problem if you<br>
put types in the same modules as code in a large project? Examples<br>
welcome, too.<br>
<div class="im"><br>
> After my blog post complaining about records, I had a few people telling me<br>
> that I can just use existing polymorphism to avoid the name-spacing issue. I<br>
> collected the approaches here: <a href="http://www.yesodweb.com/wiki/record-hacks" target="_blank">http://www.yesodweb.com/wiki/record-hacks</a><br>
> I didn't think any of those telling me what i should do had actually tried<br>
> to do this themselves, particularly at any kind of larger scale. I am<br>
> interested to see if anyone has experience trying this approach, or if you<br>
> have considered it.<br>
<br>
</div>I considered that approach but never tried it, one would probably<br>
enlist the help of TemplateHaskell to do that approach properly. Maybe<br>
it's not so bad? I suppose I could try making a few branches in my<br>
project and try out this approach.<br>
</blockquote></div><br></div></div>