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.
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. 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. On Thu, Sep 15, 2011 at 8:15 AM, Christopher Done <[email protected]>wrote: > 2011/9/15 Greg Weber <[email protected]>: > > 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 [email protected] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
