develooper Front page | perl.module-authors | Postings from October 2005

Branded naming and Rose (was: Name for module to construct URIfrom named params?)

John Siracusa
October 5, 2005 12:05
Branded naming and Rose (was: Name for module to construct URIfrom named params?)
Message ID:
On 10/5/05, Terrence Brannon <> wrote:
> 1 - GENERIC functionality would go into URI::Factory. This is
> functionality which addresses the general problem domain in a general
> way with no obvious leanings towards any particular framework.

Well, Rose::URI isn't a factory for URI objects (neither "isa" URI nor ref
$uri eq 'URI') so there'd have to be a different name, at the very least.

> 2 - DERIVED or SPECIALIZED hooks, refinements, over-rides or other
> things peculiar/unique to Rose would go into a URI::Factory::Rose
> class which would look like:

In the case of Rose::URI, there are really are no "hooks" that are specific
to Rose.  It's Rose-related because its feature set was chosen based on (and
will continue to be driven by) what other Rose modules need.

To give a slightly different example, Rose::DB does have those kinds of
Rose-specific "hooks" a-plenty, in addition to a purpose in life that is
strongly driven by Rose--RDBO, specifically.

So, why not factor out the Rose-specific stuff and/or rename these modules?
In the case of Rose::URI, like I said, I'm open to it.  But I've not been
able to come up with a name I like better.  Feel free to suggest some :)

In the case of Rose::DB, where performance is a goal, it's important for me
maintain a relatively "denormalized" (to use db terminology) implementation.
That is, one with less layering--fewer sub calls between point A and point
B.  For example, I do some pretty evil stuff inside Rose::DB to get what
essentially boils down to "delegation."

Now you may say that's "bad design," and that it should be done with proper,
generic delegation so that others can build on it.  That's probably true in
the abstract, but for me it's a question of priorities and time.

> But then again, perhaps you have the Java idea about functionality:
> people own a domain and do their development under it... the Perl
> Bivio framework works this way.

I do have a slightly more "product/package"-oriented philosophy with Rose.
Some people are turned off by the overwhelming choice of CPAN, and are
comforted by a "one-stop shopping" approach.  Now I don't buy that approach
entirely (as witnessed by the long list of non-Rose modules in Rose's
various PREREQ_PMs) but I do think there's room for some expansion in this
direction in the Perl world--or at least the appearance of it, which boils
down to the same thing.

With Rose, I'm trying to hit a sweet spot: the appearance of a "solution"
with the flexibility of traditional CPAN modules.  Truth be told, that
"tradition" includes few  modules are drop-in replacements for each other,
and many of the most popular do a poor job of providing clean access to the
layers below them.  (Try turning off the Nagle delay on the socket used by
an LWP::UserAgent object, for example.)  I think the Rose stuff is at above
average in this regard, although I admit that the "appearance" my obscure
some of this reality.  It's a balancing act, and one I continue to work on.
(The code's not exactly finished either, of course... :)

-John Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at | Group listing | About