From: Trans Date: 2007-04-28T22:41:13+09:00 Subject: Re: DHH vs. WHY style On Apr 28, 4:10 am, Clifford Heath wrote: > 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. You remind me that I didn't address module namespace in my last post -- further complicating the matter. > 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 :-). Funny how concerns can overlap even in orthogonal ways ;-) > > ...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. Actually, I've already done this very thing. "Facets 2.0" (however I end up subdividing the parts) will be a much cleaner library. But if you have a specific concerns in this regard please let me know so I can make sure they have been addressed. T.