From: Sammy Larbi <sam@...>
Date: 2007-04-30T23:02:07+09:00
Subject: Re: DHH vs. WHY style

Trans wrote, On 4/30/2007 8:42 AM:
> On Apr 29, 12:00 am, Sammy Larbi <s...@powersource.com> wrote:
>   
>>> The opposing view doesn't seem to have hurt the
>>> popularity of Hpricot, Mongrel, Hoe, or, heck, even "Rails" itself, and
>>> they're some of the biggest Ruby related projects out there ;-)
>>>       
>>> That said, I must admit I partly agree with you when it comes down to
>>> tools,
>>> rather than brand names. Rails is certainly a brand, and has almost
>>> certainly been intended to be one from very early on. Same for Hpricot
>>> and
>>> Mongrel, I'd say. Some small library with a niche function though..?
>>> I'd say
>>> your advice would be right for 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.  =)
>>     
>
>   

Thanks for the clarification. I have some more comments/questions below.

> Well, at heart, we're dealing will about 100 or so libraries (ie.
> files). The vast majority of which can stand on there own. 

What is preventing you from making them stand on their 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. 

So, now you are looking to group them into more cohesive chunks?

> 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.
>
>   

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)

> 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.
>   

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