From: Trans Date: 2007-05-01T00:41:21+09:00 Subject: Re: DHH vs. WHY style On Apr 30, 10:02 am, Sammy Larbi wrote: > Trans wrote, On 4/30/2007 8:42 AM: > > > > > On Apr 29, 12:00 am, Sammy Larbi 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? 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. > > 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? Yes. > > 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) 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. > > 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. Sorry you lost me here. But that's a good hand ;-) T.