About class methods

ruby-talk
21

Dave Howell wrote:

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.

Well, I think 'simpleton' and 'singleton' are synonymous terms (about
98% sure of that if this were a lifeline). But, the problem would
remain if singleton isn't a good fit to begin with. I actually think
singleton is a good fit and therefore so is simpleton.

--J

···

--
Posted via http://www.ruby-forum.com/\.

22

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.
:slight_smile:

--J

···

--
Posted via http://www.ruby-forum.com/\.

23

Hi --

···

On Wed, 14 Dec 2005, jonathan leonard <zjll9@imail.etsu.edu> <zjll9@imail.etsu.edu> <zjll9@imail.etsu.edu> wrote:

Dave Howell wrote:

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.

Well, I think 'simpleton' and 'singleton' are synonymous terms (about
98% sure of that if this were a lifeline). But, the problem would
remain if singleton isn't a good fit to begin with. I actually think
singleton is a good fit and therefore so is simpleton.

I think you're laboring under a misunderstanding.

Please see SIMPLETON Definition & Usage Examples | Dictionary.com

David

--
David A. Black
dblack@wobblini.net

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

24

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

···

--
Posted via http://www.ruby-forum.com/\.

25

unknown wrote:

I think you're laboring under a misunderstanding.

Please see SIMPLETON Definition & Usage Examples | Dictionary.com

I don't think so.

see:
http://foreigndispatches.typepad.com/dispatches/2005/10/the_simpleton_d.html

or do a google search for 'simpleton design pattern' for many others.

--J

···

--
Posted via http://www.ruby-forum.com/\.

26

Just for comparision:
singleton |ˈsi ng gəltən| |ˌsɪŋgəlt(ə)n| |ˌsɪŋg(ə)lt(ə)n|
noun
a single person or thing of the kind under consideration : splitting the clumps of plants into singletons.
• [often as adj. ] a child or animal born singly, rather than one of a multiple birth : singleton boys.
• (in card games, esp. bridge) a card that is the only one of its suit in a hand.
• Mathematics & Logic a set that contains exactly one element.
ORIGIN late 19th cent.: from single , on the pattern of simpleton.

···

On Dec 13, 2005, at 10:00 PM, dblack@wobblini.net wrote:

I think you're laboring under a misunderstanding.

Please see SIMPLETON Definition & Usage Examples | Dictionary.com

27

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.

28

Hi --

···

On Wed, 14 Dec 2005, jonathan leonard <zjll9@imail.etsu.edu> <zjll9@imail.etsu.edu> <zjll9@imail.etsu.edu> wrote:

unknown wrote:

I think you're laboring under a misunderstanding.

Please see SIMPLETON Definition & Usage Examples | Dictionary.com

I don't think so.

see:
http://foreigndispatches.typepad.com/dispatches/2005/10/the_simpleton_d.html

or do a google search for 'simpleton design pattern' for many others.

This seems to be some kind of play on words. "Simpleton" is not an
appropriate serious word for a language feature.

David

--
David A. Black
dblack@wobblini.net

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

29

Lol!

···

On Wed, 14 Dec 2005 03:57:35 -0000, jonathan leonard <zjll9@imail.etsu.edu> wrote:

(David Black) wrote:

I think you're laboring under a misunderstanding.

Please see SIMPLETON Definition & Usage Examples | Dictionary.com

I don't think so.

--
Ross Bamford - rosco@roscopeco.remove.co.uk
A person who is felt to be deficient in judgment, good sense, or intelligence; a fool.

30

Logan Capaldo wrote:

Just for comparision:
singleton |ˈsi ng gəltən| |ˌsɪŋgəlt(ə)n| |ˌsɪŋg(ə)lt(ə)n|
noun
a single person or thing of the kind under consideration : splitting
the clumps of plants into singletons.
• [often as adj. ] a child or animal born singly, rather than one of
a multiple birth : singleton boys.
• (in card games, esp. bridge) a card that is the only one of its
suit in a hand.
• Mathematics & Logic a set that contains exactly one element.
ORIGIN late 19th cent.: from single , on the pattern of simpleton.

What is the source of this definition? This could be my vindication. :slight_smile:

--J

···

--
Posted via http://www.ruby-forum.com/\.

31

transfire wrote:

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

···

--
Posted via http://www.ruby-forum.com/\.

32

unknown wrote:

or do a google search for 'simpleton design pattern' for many others.

This seems to be some kind of play on words. "Simpleton" is not an
appropriate serious word for a language feature.

Yea, I agree there is some word playing going on (it may be kinda like
releasing a virus into the wild). Some of what the search turned up was
making fun of the singleton pattern by calling it simpleton (and the
rest could have been accidental misuses). However, I could have sworn
that I saw this word used in a more legitimate place (such as a lecture
or textbook). If I run across a more authoritative source, I'll share
it.

Nevertheless, I have to disagree with your 'serious' requirement for
words for language features in general and, in particular, concerning
simpleton. Take for instance, 'duck typing'. And, I see nothing wrong
with simpleton either, if there were an actual language construct which
fit the word; although, I admit, it might not fit for 'singleton' as
much as I initially thought.

However, if you expand your search, you can find people refering to code
modules as simpletons, based on the fact that they have a limited,
simple set of functionality (check out this page for instance):

and it does seem to fit their architecture.

--J

···

--
Posted via http://www.ruby-forum.com/\.

33

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

···

--
Posted via http://www.ruby-forum.com/\.

34

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.

···

jonathan leonard <zjll9@imail.etsu.edu> wrote:

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?

35

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 :slight_smile: 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

···

On Sat, 10 Dec 2005, Trans wrote:

jonathan leonard <zjll9@imail.etsu.edu> wrote:

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?

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.

--
David A. Black
dblack@wobblini.net

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

36

transfire wrote:

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. :slight_smile: (makes it too hard for readers/maintainers to
understand).

···

--
Posted via http://www.ruby-forum.com/\.

37

Hi --

transfire wrote:

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?

The starting-point of the whole thing is the principle that objects
can be individually extended. Two instances of MyClass, for example,
begin life with the same capabilities (methods), but during their
lives can diverge:

   class MyClass
   end

   a = MyClass.new
   b = MyClass.new

   def a.x
   end

   def b.y
   end

The singleton class mechanism is just a way to store those "extra"
methods. The methods written for a (namely, "x") go in a's singleton
class; those for b, in b's; etc. These classes are created
automatically when they are needed.

If you want to open a class definition block for an object's singleton
class, you use the class keyword, plus "<< obj". This special syntax
is necessary because singleton classes are anonymous. Other than
that, it's very much like doing "class C".

It's all very simple and elegant, isn't it? :slight_smile:

David

···

On Sat, 10 Dec 2005, jonathan <zjll9@imail.etsu.edu> <zjll9@imail.etsu.edu> <zjll9@imail.etsu.edu> wrote:

--
David A. Black
dblack@wobblini.net

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

38

dblack@wobblini.net wrote:

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....

I tend to agree with you. While on the surface it may seem simpler
without the class, I think it actually ends being more complicated. I
think the same holds true for aop wraps --another reason to favor of
cuts over (or as a foundation for) the proposed hooks.

T.

39

It's not a subclass, it's an anonymous proxy superclass. It goes into
the inheritance chain between the object it extends and the class that
object derived from, like so (assume a is a String):

[String] --- [class << a] --- [a]

Since ruby doesn't have multiple inheritance, you can see why there can
(and need!) only be a single proxy superclass.

martin

···

"jonathan <zjll9@imail.etsu.edu> <zjll9@imail.etsu.edu> <zjll9@imail.etsu.edu>" <zjll9@imail.etsu.edu> wrote:

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?

40

dblack wrote:

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?

The starting-point of the whole thing is the principle that objects
can be individually extended. Two instances of MyClass, for example,
begin life with the same capabilities (methods), but during their
lives can diverge:

   class MyClass
   end

   a = MyClass.new
   b = MyClass.new

   def a.x
   end

   def b.y
   end

The singleton class mechanism is just a way to store those "extra"
methods. The methods written for a (namely, "x") go in a's singleton
class; those for b, in b's; etc. These classes are created
automatically when they are needed.

Hmm. Ok, so there really is no singleton class for Myclass? In other
words, must the singleton always be associated with an instance and not
a class?

If you want to open a class definition block for an object's singleton
class, you use the class keyword, plus "<< obj". This special syntax
is necessary because singleton classes are anonymous. Other than
that, it's very much like doing "class C".

It's all very simple and elegant, isn't it? :slight_smile:

Yea. That is cool, but can you still do something like this:

class Myclass
end

def extend_class( some_class )
  code = %{ class #{some_class.class}_extension < #{some_class.class}
              def new_method1
              end
              ...
            end }
  eval( code )

extend_class( Myclass )
x = Myclass_extension.new
x.new_method1
y = Myclass_extension.new
y.new_method1

Some variation of this (where the extended class is named uniquely)
should allow infinitely many extended subclasses and also allow
non-singleton (i.e., many) instances of the subclasses.

Of course, I suppose you could start with x and y as instances of the
base class and add the new_method's to each of them just as easily (and
with probably less typing). So, would there ever be a reason to do
something like I wrote above?

--J

···

--
Posted via http://www.ruby-forum.com/\.