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 ===