Changes between Version 3 and Version 4 of Records

Sep 15, 2011 9:40:42 AM (4 years ago)

Added some problems I've experienced with record name clashes.


  • Records

    v3 v4  
     56=== Problems with using the module namespace mechanism === 
     58Suppose I have 112 hand-crafted data types in my 
     59project (e.g. see attachment 51369.txt), this creates a lot of 
     60conflicts in field names and constructor names. For example: 
     63data Comment = Comment { 
     64      commentId           :: CommentId 
     65    , commentContent      :: Content 
     66    , commentReviewId     :: ReviewId 
     67    , commentSubmissionId :: SubmissionId 
     68    , commentConferenceId :: ConferenceId 
     69    , commentDate         :: ISODate 
     70    , commentReviewerNumber :: Int 
     71  } deriving (Show) 
     74This is a real type in my project. It has fields like “id”, “content”, 
     75“reviewId”, “submissionId”, “date”. There are seven other data types 
     76that have a field name “submissionId”. There are 15 with 
     77“conferenceId”. There are 7 with “content”. And so on. This is just to 
     78demonstrate that field clashes ''do'' occur ''a lot'' in a nontrivial 
     81It also demonstrates that if you propose to put each of these 112 types 
     82into a separate module, you are having a laugh. I tried this around 
     83the 20 type mark and it was, apart from being very slow at compiling, 
     84''very'' tedious to work with. Creating and editing these modules was a 
     85distracting and pointless chore. 
     87It ''also'' demonstrated, to me, that qualified imports are horrible 
     88when used on a large scale. It happened all the time, that'd I'd 
     89import, say, 10 different data types all qualified.  Typing map 
     90( . BarMu.thisField) and {{{foo Bar.Zot{x=1,y=2}}}} becomes tedious 
     91and distracting, especially having to add every type module when I 
     92want to use a type. And when records use other types in other modules, 
     93you have ''a lot'' of redundancy. With the prefixing paradigm I'd write 
     94fooId and barMuThisField, which is about as tedious but there is at 
     95least less . confusion and no need to make a load of modules and 
     96import lines. Perhaps local modules would solve half of this 
     97problem. Still have to write “ bar” rather than “mu bar”, but 
     98it'd be an improvement. 
     100I also have 21 Enum types which often conflict. I end up having to 
     101include the name of the type in the constructor, or rewording it 
     102awkwardly. I guess I should put these all in separate modules and import qualified, 
     103too. Tedious, though. At least in this case languages like C# and 
     104Java also require that you type {{{EnumName.EnumValue}}}, so c‘est la vie. 
    56107=== Type directed name resolution ===