C
Clifford Heath
Joel said:
+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.
+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.
T
Trans
I like the taxonomy too, but this naming scheme for requires is not
really ideal. These colorful names represent a repository or part of a
repository. In general, a package could just as well have lib files
that fall under variant categories, and I don't think it's a good idea
to spread them out over a number of subdirectories. So it's better as:
tapestry/aop/..
comrade/cli/...
fileside/file/...
annote/meta/... (?)
The initial names are simply namespaces that separate these libs from
other repositories/packages. If the libs were part of the standard
library, then the initial namespace could be removed. In fact it would
not be unreasonable to use a domain name for this. For example:
require 'facets.rubyforge.org/aop/...'
That's really the community friendly way of doing things. Although,
since Rubyforge is by far the most common source of all libs ruby, it
is also reasonable to omit the host name (.rubyforge.org). Indeed,
registering a project with Rubyforge gives one the right to use that
toplevel require space. Unfortunately there's a bit of an unspoken
schism in the community (which I mentioned in an older post) as to
whether it is actually the first use of a gem name that gives one a
right to a toplevel namespace instead. None of this is enforced of
course, but it's basically the unspoken standard. And 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. Since there is no general consensus on this I am left
figuring out what to call and how to tie together the repository name,
the package names and taxonomy to achieve this.
BTW, I'm really impressed with the responses thus far; lots of great
insights from all of you. Thanks guys!
T.
C
Clifford Heath
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:
NS.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
.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.
T
Trans
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:
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 ;-)
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.
S
Sammy Larbi
I'm not sure that name came from nowhere....Peter said:
(http://en.wikipedia.org/wiki/Googol) Of course, I assume most probably
knew that...
I was never sure if this thread was talking about naming
classes/packages or a product. In my view, you should name products
distinctly, and its quite ok to give them cute names. But giving
code-related things names that are nonsensical /is/ nonsensical. It may
seem cute, but its often quite useless.
After reading this one, I'm still no closer to knowing if we are talking
about products or code. =) But I'm leaning ever closer to knowing I
just don't know. =)
Sam
T
Trans
Well, at heart, we're dealing will about 100 or so libraries (ie.
files). The vast majority of which can stand on there own. I'd have to
be crazy to give each and every one a colorful name, but some of them
do admit of clear relationships, like the libs pertaining to CLI and
AOP. Presently Facets is one monolithic library collection. That's
good for brand recognition around "Facets", but it also seems to hurt
uptake b/c programmers tend to look for more focused solutions.
Per the original query. I could subdivide the libs into taxonomic
categories, eg. cliFacets, aopFacets, and what have you. That would
help, but I worry it would still not be enough to spur this focused
uptake. And I also wonder if it would still stifle development since
they remain part a larger collective.
T.
S
Sammy Larbi
Trans wrote, On 4/30/2007 8:42 AM:
Thanks for the clarification. I have some more comments/questions below.
What is preventing you from making them stand on their own?
So, now you are looking to group them into more cohesive chunks?
What about Facets as a brand, but not necessarily in the code
packaging? That way, unrelated things are not seemingly related
in creating variables, requiring files, and such. Then say "company"
Facets releases different, helpful packages. (or whatever level of
granularity you like)
I'm sure you have covered all these, but my memory fails me sometimes
and I thought I'd bring them up. The part that "concerned" me was that
I was thinking you (and/or others, in the general case) were talking
about doing something like this in the code:
require 'some_facets_file'
some_var = Ace.new
another_two = Jacks.new(2)
fourth_and_fifth = Kings(2)
Then, I don't know whether I've just been dealt Two-Pair with an Ace
kicker, where the next line should be "raise 250", or if something more
useful is happening.
Sam
Thanks for the clarification. I have some more comments/questions below.
What is preventing you from making them stand on their own?
So, now you are looking to group them into more cohesive chunks?
What about Facets as a brand, but not necessarily in the code
packaging? That way, unrelated things are not seemingly related
in creating variables, requiring files, and such. Then say "company"
Facets releases different, helpful packages. (or whatever level of
granularity you like)
I'm sure you have covered all these, but my memory fails me sometimes
and I thought I'd bring them up. The part that "concerned" me was that
I was thinking you (and/or others, in the general case) were talking
about doing something like this in the code:
require 'some_facets_file'
some_var = Ace.new
another_two = Jacks.new(2)
fourth_and_fifth = Kings(2)
Then, I don't know whether I've just been dealt Two-Pair with an Ace
kicker, where the next line should be "raise 250", or if something more
useful is happening.
Sam
T
Trans
For starters, maintaining 100+ packages would be a severe pain --
though I did seriously considered it. But really it gets too granular
at that point. We're talking about a lot of small generally useful
(albiet not necessarily commonly useful) libs.
Yea, I've been considering that option. It's a hard choice b/c many
people (including myself) tend to associate the extension methods
library with Facets --but that's just one part, albeit the core part.
So subdividing it in a _why-like way, I'm inclined to name the core
extensions package Facets. But that leaves me wondering if it makes
sense to also call the "company brand" (as you put it) Facets.
Sorry you lost me here. But that's a good hand ;-)
T.
S
Sammy Larbi
Trans wrote, On 4/30/2007 10:41 AM:
Oh, I was referring back to my original question of what the thread was
talking about. I remembered there was a playing card reference
somewhere, and it "concerned" me if you were talking about naming the
classes after cards, then reading the code I might not know what was
going on. That's all. (aside from my typos in the example)
Thanks again for helping me understand what was going on. I appreciate it.
Sam
Oh, I was referring back to my original question of what the thread was
talking about. I remembered there was a playing card reference
somewhere, and it "concerned" me if you were talking about naming the
classes after cards, then reading the code I might not know what was
going on. That's all. (aside from my typos in the example)
Thanks again for helping me understand what was going on. I appreciate it.
Sam
M
Michal Suchanek
Also I would not want to search for a library named Aces. Nor I would
try as I usually search for solution to a particular problem, and Aces
does not sound like anything I was ever solving.
Although more capable search engines would also pick keywords from
description, I am not sure about the current situation on Rubyforge
and elsewhere.
But I am pretty sure Facets never fell out of the search engines for
me. Maybe they are for stuff that I do not use. I don't know.
Thanks
Michal