2011/9/15 Greg Weber <g...@gregweber.info>:
> 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.
Ah, this is because my approach to types is to put them in a
ProjectName.Types.X module. I /do/ have separate modules for all my
models, e.g.
$ ls Confy/Model/*.hs
Confy/Model/Actions.hs Confy/Model/Driver.hs
Confy/Model/Manuscript.hs Confy/Model/Proceedings.hs
Confy/Model/SubmissionAuthor.hs Confy/Model/Token.hs
Confy/Model/Activity.hs Confy/Model/Fields.hs
Confy/Model/Message.hs Confy/Model/ReviewComment.hs
Confy/Model/Submission.hs Confy/Model/Track.hs
Confy/Model/Author.hs Confy/Model/FormField.hs
Confy/Model/Papertype.hs Confy/Model/ReviewerPreference.hs
Confy/Model/Tables.hs Confy/Model/User.hs
Confy/Model/Conference.hs Confy/Model/Form.hs
Confy/Model/Participant.hs Confy/Model/Review.hs
Confy/Model/Template.hs Confy/Model/UserMeta.hs
Confy/Model/Deadline.hs Confy/Model/LogEntry.hs
Confy/Model/Period.hs Confy/Model/Role.hs Confy/Model/TH.hs
Confy/Model/Utils.hs
I have my HaskellDB types and then I have my normal Haskell types
which contain different fields to the database model.
But to put the /type/ in the model file itself causes cyclic import
problems when I have to start caring about what imports what and then
having modules that just contain types, etc. I find this to be quite
laborious, I did it at first but it became a hindrance to development
practice for me. Have you not found that you have this problem if you
put types in the same modules as code in a large project? Examples
welcome, too.
> 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.
I considered that approach but never tried it, one would probably
enlist the help of TemplateHaskell to do that approach properly. Maybe
it's not so bad? I suppose I could try making a few branches in my
project and try out this approach.
_______________________________________________
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
