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
Hi! When I read the Ruby manual, I noticed that for class Array, there are
class methods and instance methods.Class methods:
and newinstance 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 x;
x.anInstanceMethod( ); //=> returns 7
On Dec 8, 2005, at 1:30 AM, Hank Gong wrote:
A::aClassMethod( ); //=> returns 42
Hank Gong wrote:
Hi! When I read the Ruby manual, I noticed that for class Array, there are
class methods and instance methods.Class methods:
and newinstance 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
Ruby Code & Style - 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
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 
They're not eigenmethods are they?
Actually, they are ad hoc. 
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.
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
On 12/8/05, Trans <transfire@gmail.com> wrote:
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.
I'm curious why "class method" is being avoided? It certainly seems
accurate and matches the use of class methods by languages such as Smalltalk
and Objective-C.
On 12/8/05, Trans <transfire@gmail.com> wrote:
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.
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.
On Fri, 9 Dec 2005, Hank Gong wrote:
--
David A. Black
dblack@wobblini.net
"Ruby for Rails", forthcoming from Manning Publications, April 2006!
Mark Ericson wrote:
I'm curious why "class method" is being avoided? It certainly seems
accurate and matches the use of class methods by languages such as Smalltalk
and Objective-C.
I think "class method" is used in our community, but it is considered
a special case -- it's just a singleton method on an object which happens
to be a class. A singleton method on an object which isn't a class --
well, that obviously isn't a class method.
Hal
dblack@wobblini.net wrote:
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
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.
Heu magister carbunculi!
Ridens magna voce
Iohannes
On 12/8/05, dblack@wobblini.net <dblack@wobblini.net> wrote:
I'm not sure I agree that it's ad hoc where the
"hoc" (actually the "hic", I guess, in the nominative case
object itself.
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".
On Mon, Dec 12, 2005 at 03:30:50PM +0900, Hal Fulton wrote:
Mark Ericson wrote:
>I'm curious why "class method" is being avoided? It certainly seems
>accurate and matches the use of class methods by languages such as
>Smalltalk
>and Objective-C.I think "class method" is used in our community, but it is considered
a special case -- it's just a singleton method on an object which happens
to be a class. A singleton method on an object which isn't a class --
well, that obviously isn't a class method.
--
Chad Perrin [ CCD CopyWrite | http://ccd.apotheon.org ]
unix virus: If you're using a unixlike OS, please forward
this to 20 others and erase your system partition.
transfire wrote:
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
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.
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
I advocate "pouch"
In any case, it might be wise to hold some sort of a poll (or perhaps
Matz can be coerced to pick the one he prefers) because I have noticed
a trend of different groups using different terms for the same thing
which in turn has caused some confusion about the feature in general.
E
On 2005.12.12 17:07, Chad Perrin <perrin@apotheon.com> wrote:
On Mon, Dec 12, 2005 at 03:30:50PM +0900, Hal Fulton wrote:
> Mark Ericson wrote:
> >I'm curious why "class method" is being avoided? It certainly seems
> >accurate and matches the use of class methods by languages such as
> >Smalltalk
> >and Objective-C.
>
> I think "class method" is used in our community, but it is considered
> a special case -- it's just a singleton method on an object which happens
> to be a class. A singleton method on an object which isn't a class --
> well, that obviously isn't a class method.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."
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".
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
On Dec 8, 2005, at 3:45 PM, jonathan <zjll9@imail.etsu.edu> <zjll9@imail.etsu.edu> <zjll9@imail.etsu.edu> wrote:
Dave Howell 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".
--snip--
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.
Well, then there is obviously only one logical choice:
Chunky Bacon Class!
Regards,
Michael
On Dec 12, 2005, at 0:07, Chad Perrin wrote:
--
Michael Ulm
R&D Team
ISIS Information Systems Austria
tel: +43 2236 27551-219, fax: +43 2236 21081
e-mail: michael.ulm@isis-papyrus.com
Visit our Website: www.isis-papyrus.com
Hi --
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
On Tue, 13 Dec 2005, Dave Howell wrote:
On Dec 12, 2005, at 0:07, Chad Perrin wrote:
--
David A. Black
dblack@wobblini.net
"Ruby for Rails", forthcoming from Manning Publications, April 2006!
Dave Howell wrote:
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.
I believe, and there is a slight chance that I'm wrong, that the terms
simpleton and singleton are synonymous.
--J
--
Posted via http://www.ruby-forum.com/\.