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