David A. Black wrote:
> Hi --
>
> On Fri, 9 Nov 2007, 7stud -- wrote:
>
>>>
>>> The term "class method" can refer to either of two things: an instance
>>> method of Class, or a singleton method of a given class.
>>>
>>
>> Wouldn't it be more proper to call an instance method of Class a "Class
>> method" rather than a 'class method'.
>
> No, I don't think that distinction is useful. You can certainly make
> the distinction between instance methods of Class and singleton
> methods of Class objects, but in practice, they're both frequently
> referred to as "class methods".
>
Ok.
>>
>> Based on your explanation, I think that is a clear case for the errata.
>
> I think the terminology gets a bit circular at the top of the tree.
>
Yes, it's quite confusing up there.
>
> inherited is (at least in 1.8.6) defined as a private instance method
> of Class.
>
Then I find the listing for Class in the pickaxe2 reference section
completely out of sync with the rest of the reference section, which
clearly makes distinctions between "Class methods"(with a capital 'C'),
Instance methods, and Private Instance methods. My overriding thought
is: "you can't have it both ways". If you say all methods of Class are
'class methods', then in the listing for Class, all the methods should
be under one heading--not like this:
Class methods:
inherited
...
new
...
Instance methods:
allocate
...
new
..
superclass
To me, those categories say that allocate and inherited are different in
some way. According to your explanation, they are not. If you want to
say all methods in Class are 'class methods', then the listing should be
consistent with that thought, e.g.:
class methods(with a little 'c'):
inherited
...
new
...
allocate
...
superclass
...
or more accurately(which would be my preference):
Private instance methods:
inherited
...
new
...
allocate
...
superclass
...
> My experience is that instance methods of Class or Module
> are often referred to as "class methods".
Ok.
> For example, it's common to
> refer to attr_accessor as a class method. I don't know whether that
> was Dave's thinking in listing it as a class method. It's also a
> slightly edge case since it doesn't really do anything unless you
> override it.
>
>
Thanks for the explanation.
--
Posted via
http://www.ruby-forum.com/.