Why I (Don't!) Want Global Field Names (By Default)

[AntC]

Gershom Bazerman <gershomb <at> gmail.com> writes:

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