Hi --

On Tue, 13 Dec 2005, Dave Howell wrote:

>
> On Dec 12, 2005, at 0:07, Chad Perrin wrote:
>
>> By the way . . . has anyone considered a name like "singular"?  What
>> about "ad lib" instead of "ad hoc"?
>> 
>> I've gotta say, though, that I'm partial to the descriptor "eigen".
>
> Well, I'm having a terrible time following the distinction between the 
> indefinite number of flavors of this difficult-to-name type of method, but I 
> do know something about naming things. :)
>
> Generally, trying to find an existing term, like 'singleton' or 'ad hoc', is 
> a good thing, because lets somebody bring pre-constructed expectations to the 
> process, hopefully saving them time in learning how this particular thing 
> works.
>
> Unless, of course, different people have different expectations for that 
> word, or if the thing in question contradicts the expectations in some way.
>
> If 'simpleton' and 'singleton' are equally applicable to either of two 
> different cases, as somebody suggested earlier, then these will lead people 
> to *think* they know what will happen, but there's a 50/50 chance that it 
> will be the other. So that's not a good thing. There appears to be some 
> concern that "ad hoc" implies something much broader (?) than this particular 
> usage actually has. That's not a good thing.
>
> If you have a situation where none of the existing reasonable terms seem like 
> an adequately non-confusing match, then it's actually much better to use a 
> term that *doesn't* bring a lot of pre-conceived baggage to the table. If you 
> create a term that's *obviously* meaningless or ambiguous, then the 
> first-time user knows right away that they'll have to look it up, instead of 
> erroneously thinking they know what it does just because of the name. Calling 
> them something like "intral methods", "uni methods", "anonic methods," or 
> "eigenz" is better than using a "real" pre-existing word that is a poor fit. 
> "Hmm. Uni methods. Well, I have a hunch what that might be for, but it isn't 
> immediately obvious. I'll just have to read more about it to find out what 
> they actually do."

A couple of problems with that, in this particular case:

First, there's an existing term (singleton method/class) that's under
review by Matz, with input from the community.  That means that
calling them "potato-peel classes", or whatever, not only adds
confusion but short-circuits a process that's already underway and
that promises to result in a decision and clarification.

Second, you can't read more about the thing if you don't know what
it's called.  All this renaming just adds an extra layer of having to
learn about the history of ruby-talk, as well as the features of the
Ruby language, in order to know what people are talking about in the
first place.  The advantages of this elude me.  I think the community
would be well advised not to assume that the world's interest in
keeping track of who uses which home-made synonym for "singleton
class" is unlimited.


David

-- 
David A. Black
dblack / wobblini.net

"Ruby for Rails", forthcoming from Manning Publications, April 2006!