About class methods

[Hank Gong]

------=_Part_10208_29744842.1134023392814
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

Hi! When I read the Ruby manual, I noticed that for class Array, there are
class methods and instance methods.

Class methods:
[] and new

instance methods:
too many (not list here)

My question is: what's this class methods? I remember in C++, all methods
should be instance level, right?
Thanks!

Yours, Hank

------=_Part_10208_29744842.1134023392814--

 

[Logan Capaldo]

Hi! When I read the Ruby manual, I noticed that for class Array,
there are
class methods and instance methods.

Class methods:
[] and new

instance methods:
too many (not list here)

My question is: what's this class methods? I remember in C++, all
methods
should be instance level, right?
Thanks!

Yours, Hank

class methods are (more or less) the same thing as static methods in C
++.

eg.

class A
{
public:
static int aClassMethod { return 42; }
int anInstanceMethod { return 7; }
};

A::aClassMethod( ); //=> returns 42
A x;
x.anInstanceMethod( ); //=> returns 7

 

[James Britt]

Hi! When I read the Ruby manual, I noticed that for class Array, there are
class methods and instance methods.

Class methods:
[] and new

instance methods:
too many (not list here)

My question is: what's this class methods? I remember in C++, all methods
should be instance level, right?

p Array.class # Class
p Array.instance_of? Class # true


Array is an instance of Class, so those methods are, in a way, instance
methods.


No?


They're not eigenmethods are they?






James
--

http://www.ruby-doc.org - Ruby Help & Documentation
http://www.artima.com/rubycs/ - Ruby Code & Style: Writers wanted
http://www.rubystuff.com - The Ruby Store for Ruby Stuff
http://www.jamesbritt.com - Playing with Better Toys
http://www.30secondrule.com - Building Better Tools

 

[Trans]

In Ruby a class is an object too. So it can have it's own methods just
like any other object. There methods are different from a class
instance methods, which are the ones that define the nature of an
object instantiated from the class. So lets say we have a class:

class MyClass
end

Then we can treat is like any other object and send messages to it.

MyClass.object_id #=> -606921464

That's what is called a *class method*. Also, you may have noticed that
you can define a method tailored specifically for any object. For
instance:

a = "hi"
def a.up
self.upcase
end
a.up #=> "HI"

Class methods are actually the same thing. You can create one of these
tailor-made methods for a class likewise:

def MyClass.upname
name.upcase
end
MyClass.upname #=> "MYCLASS"

HTH,
T.

(Hey all, I didn't use the term adhoc! See I can take a hin... I mean a
brick to the head ;-)

 

[Trans]

They're not eigenmethods are they?

Actually, they are ad hoc. ;-)

 

[Trans]

Sorry Hank, if you are unware of what were talking about in these last
two posts. We're refering to a very recent thread that discussed what
to call these type of methods. Presently they are known a "singleton
methods", but becuase of the clash with what is known in OOP generally
as the *singleton pattern*, there is on-going discussion on finding a
better term. Recent alternative suggestions are "eigen" and "adhoc".

T.

 

[Hank Gong]

------=_Part_17879_27302168.1134066608464
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

I carefully read two articles about classmethods and singleton concept.
Now for me, the concept of classmethods seems not difficult for me now. It'=
s
just singleton methods for a class because class is also a object.
However, the concept of singleton still not clear for me, also how to use
them is also not making sense for me.

Yours, Hank

Sorry Hank, if you are unware of what were talking about in these last
two posts. We're refering to a very recent thread that discussed what
to call these type of methods. Presently they are known a "singleton
methods", but becuase of the clash with what is known in OOP generally
as the *singleton pattern*, there is on-going discussion on finding a
better term. Recent alternative suggestions are "eigen" and "adhoc".

T.

------=_Part_17879_27302168.1134066608464--

 

[dblack]

Hi --

I carefully read two articles about classmethods and singleton concept.
Now for me, the concept of classmethods seems not difficult for me now. It's
just singleton methods for a class because class is also a object.
However, the concept of singleton still not clear for me, also how to use
them is also not making sense for me.

Basically an object's singleton class is a class created ad hoc, and
in a sense retroactively, for the sole purpose of being
the-class-where-this-object's-singleton-methods are defined and live.


David

P.S. Aside to Tom S.: I agree it's ad hoc in the sense of being for a
specific purpose, but I'm not sure I agree that it's ad hoc where the
"hoc" (actually the "hic", I guess, in the nominative case is the
object itself. One then runs into questions like: are instance
variables "ad hoc" variables? etc.

 

[Trans]

P.S. Aside to Tom S.: I agree it's ad hoc in the sense of being for a
specific purpose, but I'm not sure I agree that it's ad hoc where the
"hoc" (actually the "hic", I guess, in the nominative case is the
object itself. One then runs into questions like: are instance
variables "ad hoc" variables? etc.

Interesting. Perhaps we've met halfway then. 'Ad hoc' is an excellent
discriptive term, but in trying it on for size some more, so to speak,
I'm not as certain that it makes a good *techncal* term, not because of
negative conotations, but because it may be too generic, much like
'meta'. Which I think it is what you're pointing out here. Of course,
this might be a problem with any term that doesn't already have a
fitting techincal meaning.

T.

 

[jonathan]

Interesting. Perhaps we've met halfway then. 'Ad hoc' is an excellent
discriptive term, but in trying it on for size some more, so to speak,
I'm not as certain that it makes a good *techncal* term, not because of
negative conotations, but because it may be too generic, much like
'meta'. Which I think it is what you're pointing out here. Of course,
this might be a problem with any term that doesn't already have a
fitting techincal meaning.

T.

What did you guys think about using simpleton to refer to these
methods/classes? That way there can be differentiation between a class
which was made single by 'include singleton' (that is, has one single
instance somewhere) and a class which is made single (or simple) by
having only class methods and class data. The one which is an instance
of the design pattern could be called 'singleton' (since it isn't the
one in question anyway) and the other could be called 'simpleton'.

--J

 

[gwtmp01]

What did you guys think about using simpleton to refer to these
methods/classes?

I'd vote no on that name regardless. If you think 'ad hoc' has
negative connotations...

That way there can be differentiation between a class
which was made single by 'include singleton' (that is, has one single
instance somewhere) and a class which is made single (or simple) by
having only class methods and class data.

Are you confusing a class that has no instances (yet) with the class
returned by the expression (class <<obj; self; end) ?

I don't see anything particularly special or interesting about a class
with no instances (I *think* that is what you mean by a class
with 'only class methods and class data'). Certainly that isn't what
all the hubbub has been about regarding 'meta/eigen/singleton/shadow'.


Gary Wright

 

[Sean O'Halpin]

I'm not sure I agree that it's ad hoc where the
"hoc" (actually the "hic", I guess, in the nominative case is the
object itself.

Heu magister carbunculi!

Ridens magna voce

Iohannes

 

[jonathan]

Are you confusing a class that has no instances (yet) with the class
returned by the expression (class <<obj; self; end) ?

I don't think so. The expression you wrote is an example of what has
been called a singleton but, it has no methods at all (neither class nor
instance).

I don't see anything particularly special or interesting about a class
with no instances (I *think* that is what you mean by a class
with 'only class methods and class data'). Certainly that isn't what
all the hubbub has been about regarding 'meta/eigen/singleton/shadow'.

I got the impression from the other thread on this that this is what the
hubbub is about. Given a class that allows one instance to be
instantiated, some optional class data members, some instance data
members, and some class methods and instance methods and another class
that allows only class data and class methods, there is no difference
*in essence*. The argument was what to call the second sort of class.

So, in other words, the difference between these two classes is really
the fact that you can refer to some data in the first type as instance
data, but since there's only one instance, that's really no different
than class data (except for syntax of course). In essence, these two
types of classes are the same and therefore matz's original corrected
term for the second type 'singleton' fits. But, it is easily confused
with the 'true' singleton which is an instance of the design pattern
singleton (and the first class described above).

However, to eliminate ambiguity between the two, we need a term for the
second type of class (which is called a 'static class' in c# or c++, but
can't be in ruby because it is a dynamic language).

My proposal of simpleton is really arbitrary--either class could be
singleton and the other simpleton, but since more would have to be
changed to make the first type simpleton, i suggested the second. And,
however much dislike you have for 'simpleton' it is accepted as a
synonym for singleton.

I do understand of course, that enforcing such a subtle difference in
terminology is impossible and agree with the other posters that there is
most likely going to be umpteen different ways of referring to these
classes (and methods).

I should also put a disclaimer on everything I just said above which
could be totally off base: I'm coming from a 'compiled' bkg and this
commentary might not make sense in an interpreted world. I do want to
be corrected if I'm totally off-base with this, so please enlighten me.

Nevertheless, even my misunderstandings should prove useful to someone.


--J

 

[jonathan]

My understanding of 'singleton' methods or 'ad hoc' methods or
'eigenmethods' or classes of each of these came from this post (by
transfire):

(you can call methods of a module without mixing it in right?)

Yes, if they are "module methods" as opposed to instance methods.
Modules methods, (also called class methods but usually in the context
of class) are singleton methods, or adhoc methods (my new prefered
term). You can tell this by the way they are defined --the name of the
object proceeds the method name in the def statement (eg. 'def
ImageBob.get_blob'). Another way to write them:

module ImageBlob

class << self # opens adhoc context

def get_blob
...
end

end

end

T.

So, a class with only 'ad hoc' methods would be an 'ad hoc' class or
singleton, or eigen or static or whatever term you choose.

Hope this helps to get us back on the same page.

--J

 

[Trans]

J,

I think the static class idea has thrown you off a bit. Not that I'm an
expert on C#, but from what I've read it looks like a static class is
how one implements the singleton _pattern_ in C#. While Ruby has
singleton.rb with its Singleton mixin to do this kind of thing, it's
not nearly as useful b/c one can also use a module and its "singleton
class" (i.e. adhoc/eigenclass) to get much of the same effect. The
irony here, is though they can overlap in usage the later is actually
quite different and has more uses.

So forget about the C# stuff for a moment and have a read of this page,

http://rubygarden.org/ruby?SingletonTutorial

That should clarify things for you.

T.

 

[jonathan leonard]

I think the static class idea has thrown you off a bit. Not that I'm an
expert on C#, but from what I've read it looks like a static class is
how one implements the singleton _pattern_ in C#.

Well, actually, I think you do it the same way you would in C++, i.e.,
you have a static data member that is the ptr to the one instance
(starting out as NULL) and the first time the constructor is called, you
init it, and everytime after that, return the instance ptr. (There are
other ways involving private constructors)). Though, my discussion
above points out how, in essence, a static class is a singleton class
(barring syntax differences).

The only reason I had this static class == singleton equivalence in my
head was due to the actual example we were dealing with which was a
class with two singleton methods (and no other methods or instance data
members). So, a class which contains only singleton methods would not
be considered a singleton class?

While Ruby has
singleton.rb with its Singleton mixin to do this kind of thing, it's
not nearly as useful b/c one can also use a module and its "singleton
class" (i.e. adhoc/eigenclass) to get much of the same effect. The
irony here, is though they can overlap in usage the later is actually
quite different and has more uses.

So forget about the C# stuff for a moment and have a read of this page,

http://rubygarden.org/ruby?SingletonTutorial

Thanks for the link. Yea, that does look like some powerful stuff.
Seems to me that this sort of singleton (using the >> syntax) could be
known as a 'singleton subclass' or a 'singleton extension.' Any given
class can have infinitely many singleton subclases, no?

--J

 

[jonathan leonard]

T,

Any given
class can have infinitely many singleton subclases, no?

Oops. This statement from the page you linked to seems to answer that
question:

If 'a' already has a singleton class then any more singleton methods you
define are just added to it.

Does this mean that a class can have only one singleton subclass and
that all methods added anywhere in the program are added to that single
instance? If so, I wonder why this is. It seems to me to be more
useful if you can have infinitely many singleton subclasses. I suppose
you still can have divergence of this sort with individual instances,
but why not with the class itself?

--J

 

[Trans]

T,


Oops. This statement from the page you linked to seems to answer that
question:

If 'a' already has a singleton class then any more singleton methods you
define are just added to it.

Does this mean that a class can have only one singleton subclass and
that all methods added anywhere in the program are added to that single
instance? If so, I wonder why this is. It seems to me to be more
useful if you can have infinitely many singleton subclasses. I suppose
you still can have divergence of this sort with individual instances,
but why not with the class itself?

Well, I think its basically because Matz used the class nothing more
then an easy way to implement ad hoc methods. It was the methods that
mattered to him, not the class --the class was just a vehicle. He's
talked about the possibility of not utilizing the class in the future.
I assume that means these methods would then just exit in a separate
underlying namespace of the class, as opposed to a separate class
altogether. Which may also be the reason he's allowed then name to
remain a bit amorphis and never provided a convenience method for
accessing it.

T.

 

[dblack]

Well, I think its basically because Matz used the class nothing more
then an easy way to implement ad hoc methods. It was the methods that
mattered to him, not the class --the class was just a vehicle. He's
talked about the possibility of not utilizing the class in the future.
I assume that means these methods would then just exit in a separate
underlying namespace of the class, as opposed to a separate class
altogether. Which may also be the reason he's allowed then name to
remain a bit amorphis and never provided a convenience method for
accessing it.

The latter, yes, from what Matz has said (no convenience method
because it may not be a class in the future). The former -- amorphous
name -- no:

I am using the term "singleton class", and I will use
it until we find the better term as I said in [ruby-talk:141548]
7 months ago in the famous Ilias thread.

That sounds pretty non-amorphous But the whole thing may indeed
become non-class-based. I'm not sure what that would entail. I kind
of think that if it were something other than a class, one would end
up longing for a "class interface" to it, and then it might as well be
a class....


David

 

[jonathan]

Well, I think its basically because Matz used the class nothing more
then an easy way to implement ad hoc methods. It was the methods that
mattered to him, not the class --the class was just a vehicle. He's
talked about the possibility of not utilizing the class in the future.
I assume that means these methods would then just exit in a separate
underlying namespace of the class, as opposed to a separate class
altogether. Which may also be the reason he's allowed then name to
remain a bit amorphis and never provided a convenience method for
accessing it.

Hmm.. Ok. But, with Ruby, you can still dynamically create subclasses
that aren't singletons and extend them as well as instanciate instances
of them, right? That would provide the flexibility I was referring to
above, but I suppose it would require typing quite a few more
characters. So do I understand correctly that Matz designed the whole
singleton creation mechanism ( << ) as a shorthand for doing more
long-winded dynamic creation/enhancing?

--J

BTW, I haven't said so explicitly yet (but it might be gathered from
other posts) that I think Ruby is a very cool language. I've always had
an interest in self-modifying code and of the langs I've studied so far,
Ruby makes it the most sane. Of course, we aren't supposed to be doing
that stuff anyway. (makes it too hard for readers/maintainers to
understand).