From: Clifford Heath <no.spam@...>
Date: 2007-04-28T17:10:05+09:00
Subject: Re: DHH vs. WHY style

Trans wrote:
>> +1. In fact I have a whole taxonomy of infrastructure
>> terms I've used, and being able to locate a "body of
>> work" is much easier if such a taxonomy is used.

> I like the taxonomy too, but this naming scheme for requires is not
> really ideal.

Agree. The taxonomy idea is for locating a relevant
term, but because it places each term at exactly
one place in the hierarchy, it's not necessary to
use the whole hierarchy in names. So for example,
under my category "network/binding" there is a term
"DNS", which is the network binding for the domain
name system. If Ruby were to have an integrated and
definitive DNS API, it could reasonably be called
module DNS, rather than Network::Binding::DNS.

A definitive extension that adds support for DNS
service requests should be called DNS::Service.
The important point is that the library must (aspire
to) completely cover the conceptual space allocated
by that area of the taxonomy. If it doesn't, then
give it a wacky name under the place of best fit.

So if someone then came along and made a nice library
for doing something special like using DNS Service
requests to locate Windows domain controllers, it
would get called DNS::ColorfulName, and required as
"colorfulname". So the taxonomy exists really only
for the "accepted standard" way of doing things,
and as assistance in locating non-standard things.

I've also used what I call "facet naming". For example,
NT is a category under Operating Systems, and Kerberos
is a category under Security, so when I had a module
that did something with Kerberos, but was limited to
NT, the module got a parenthesized qualification added
to its name: "Security/Kerberos (NT)". The parenthetical
qualification identifies this as being top-level Kerberos
functionality, but pertaining only to NT. In this case
a Ruby module name would be Kerberos::NT, and the require
would be "kerberos/nt". The re-use of a term "NT" that's
defined elsewhere in the taxonomy identifies this as a
facet name, rather than a sub-category.

Using facet naming, every object "belongs to" one area
(Kerberos here) but potentially "pertains to" another
one (NT). This allows full aspect-oriented naming of
cross-cutting concerns.

Anyhow, I don't know whether any of these concepts have
value for the current problem, but I thought that with
your penchant for AOP and the fact that the current
subject is your Facets library, you'd be interested :-).

> ...it clarifies the
> difficulty of what I am attempting b/c it means 1) I have to figure
> out how to organize and name the redistributable subsections of this
> large repository and 2) figure out how that should effect the require
> namespaces.

Can I ask that you clearly identify and perhaps separate
items from Facets that have a strong potential to interact
and break other frameworks? I really like most of Facets,
but sometimes I just can't bear the risk of partly-hidden
strangeness.

Clifford Heath.