Gershom Bazerman
... I want to put forward at least one strong motivation for global field names (aka SORF-style) rather than locally declared field names as a default.
Hi Gershom, One of the things that's surprised me contributing to this thread is not just that different people rate different features with different priority (that's common in requirements analysis, to try to 'weight' each objective); but that what some people think is absolutely critical others think is absolutely to be avoided. (The Best example of that is the furore about dot notation.) So you're not going to expect me to agree with you. A couple of very strange things I noticed about your expectations for software development, so I'm happy to make clear the context I'm expecting: * Yes, I expect you "to pull in the entire namespace for [the] database at once". That is: in a large-scale database-oriented application, you would declare **all** your field labels (aka data dictionary) in one module, and import that into every sub-module. That's been standard practice in all the software shops I've worked in since around 1984 (System/38). That's exactly what Chris Done's example did, which started my thinking around what became DORF. I am, frankly, astonished anyone would contemplate any other approach in this day and age. Because ... * As you say, tracing all the dependencies from code mods is hard work. Developers are very poor at it. Computers are superb. I expect you to run a nightly build, why not make it easy for yourself? http://www.joelonsoftware.com/articles/fog0000000023.html http://www.joelonsoftware.com/articles/fog0000000043.html Those articles date from over a decade ago! Software shops I've worked in have run nightly builds since around mid-90's. (It'd be interesting to hear from the ghc dev team: do they run a nightly build? Although ghc is not a database-intensive application.) And what on earth sort of hardware are you running that your builds are "time consuming"? This is just not an issue in 2012. I expect large-scale applications with (say) hundreds of tables, thousands of fields, 100k's LOC to rebuild in a few hours. So to my substantive answer: * The realistic situation in modern software engineering is that you assemble your application out of libraries/packages. * You have no control over the naming used in them. * What's worse, developers are so used to strong namespacing controls, that they often use generic names that are likely to appear elsewhere. (And especially if it's in a technical domain with well-agreed jargon.) * So you're highly likely to get clashes 'by accident'. * Haskell's module/namespacing controls are perfectly adequate to manage this. * And OO, as a technique insists on namespace control, to implement encapsulation/representation-hiding. * In database-oriented applications, re-using the same name on different tables is deliberate and intentional (_not_ by accident). * H98 is simply awful for this. DORF addresses that issue. * That said, nothing in DORF stops you creating global names: simply export/import them everywhere unqualified. See: that wasn't too painful, was it? So our point of difference comes down to: what behaviour "By Default". * DORF expects it's more likely you'll want namespace control. And makes it hardly more difficult to be global. And uses module-based namespace control that is already industry-standard, viz: Haskell 98's approach. * SORF 'imposes' global everywhere, And makes it possible but awkward to control name scope. My litmus test for your approach (as for Ian's): * My record has fields `x`, `y`, and `z`: - `x` is to be gettable and settable - `y` is to be gettable but not settable - `z` is to be hidden and unguessable Please explain how your PrivateLabel approach handles those. It's not a case of whether it's possible, but rather how awkward. AntC