Why I (Don't!) Want Global Field Names (By Default)
anthony_clayden at clear.net.nz
Mon Mar 5 11:00:49 CET 2012
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.
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?
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.
More information about the Glasgow-haskell-users