| 56 | | === Problems with using the module namespace mechanism === |
| 57 | | |
| 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: |
| 61 | | |
| 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 | | }}} |
| 73 | | |
| 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. |
| 80 | | |
| 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. |
| 86 | | |
| 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 | | (Foo.id . 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.mu bar” rather than “mu bar”, but |
| 98 | | it'd be an improvement. |
| 99 | | |
| 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. |
| 105 | | |
| 106 | | -------------------------- |
