Changes between Version 6 and Version 7 of Records

Sep 15, 2011 9:56:19 AM (4 years ago)

removed problems with namespace part


  • Records

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