Forum: Ruby injecting dynamic methods into a class

Announcement (2017-05-07): www.ruby-forum.com is now read-only since I unfortunately do not have the time to support and maintain the forum any more. Please see rubyonrails.org/community and ruby-lang.org/en/community for other Rails- und Ruby-related community platforms.
47fb897113ebddae565f2f4b9f45ca1d?d=identicon&s=25 johanatan (Guest)
on 2005-12-04 05:11
hi All,

I posted this message to the Ruby on Rails group yesterday, but I
suppose it belongs here instead.

I've been trying to wrestle dynamic code generation into place for a
week now with no success.  What I want is a module or class (started
trying to use module but finished up trying to use a class) which can
inject a method into its consumer which will allow:

user.image = #<Ruby:File>

as you would get from a file upload.  (This eliminates any need for
special image handling code in the view or controller and lets the image
field act like any other).  It uses the RMagick library to convert all
images to jpg's and resize them to a consumer-defined size.  What I was
hoping the group could help with was moving all the code out of the
model and into my ImageBlob class (which will inject necessary code into
the model (i.e., consumer)).  Here's what I currently have (which
works):

model.rb
----------
def image=( file )
  write_attribute( 'image', ImageBlob.getBlob( file, 225 ))
end
def thumbnailImage=( file )
  write_attribute( 'thumbnailImage', ImageBlob.getBlob( file, 125
))
end

ImageBlob.rb
------------
require 'RMagick'
include Magick

class ImageBlob
  def ImageBlob.getBlob( file, maxImageSize )
    #omitted code which resizes and reformats image and returns blob
  end
end

I was hoping to have an initialize function in ImageBlob which would
take the consumer class and inject the necessary methods into it (image=
and thumbnailImage=).  Here's my best attempt at that (which fails for
an unknown reason):

def initialize( attributesAndSizesHash, consumerClass )
  attributesAndSizesHash.each_pair {|attributeName, maxImageSize|
    code = "class #{consumerClass}
              def #{attributeName}=( file )
                write_attribute( '#{attributeName}', ImageBlob.getBlob(
file, #{maxImageSize} ))
              end
            end"
    eval( code ) }
end

I also tried making 'code' define a module and calling
consumerClass.extend( moduleName ).  Neither of these approaches are
working.

Of course, if this implemention could work, then consumers of the
ImageBlob class could simply call:

ImageBlob.new( { "image" => 225, "thumbnailImage" => 125 }, self )

in their class definition to have the functionality added (with
any number of image fields each having their own size).

Can anyone out there provide the last piece of this puzzle?

Thanks much,
Jonathan
1fba4539b6cafe2e60a2916fa184fc2f?d=identicon&s=25 dblack (Guest)
on 2005-12-04 05:36
(Received via mailing list)
Hi --

On Sun, 4 Dec 2005, johanatan wrote:

> user.image = #<Ruby:File>
> model.rb
> ------------
> take the consumer class and inject the necessary methods into it (image=
>             end"
> ImageBlob.new( { "image" => 225, "thumbnailImage" => 125 }, self )
>
> in their class definition to have the functionality added (with
> any number of image fields each having their own size).
>
> Can anyone out there provide the last piece of this puzzle?

I don't know if this is an exact fit, but I've tried to model it on what
your example.  The basic idea here is to call class_eval on the class
that's passed in, and proceed from there (defining the methods).

  class ImageBlob
    def self.get_blob(*args)
      puts "In ImageBlob.get_blob"
    end
  end

  class MyClass
    def initialize(attrs_and_sizes, klass)
      attrs_and_sizes.each_pair do |attr_name,max_image_size|
        klass.class_eval do
          define_method("#{attr_name}=") do |file|
            write_attribute(attr_name,
                            ImageBlob.get_blob(file,max_image_size))
          end
        end
      end
    end
  end

  class OtherClass
    def write_attribute(*args)
      puts "In write_attribute"
    end
  end

  m = MyClass.new({"a" => 10, "b" => 20}, OtherClass)
  OtherClass.new.a = 2

(If you're passing in a classname string, rather than a class, you'd
also
want to do some variant of const_get to get the class itself before
class_eval'ing from it.)


David Black
45196398e9685000d195ec626d477f0e?d=identicon&s=25 transfire (Guest)
on 2005-12-04 05:44
(Received via mailing list)
If you don't mind while I'm at this I'm going to touch up the code to
follow ruby conventions.

  def initialize( attr_and_sizes_hash, consumer_class )
    attr_and_sizes_hash.each {|attr_name, max_size|
      code = %{
        def #{attr_name}=( file )
          write_attribute( '#{attr_name}', ImageBlob.getBlob( file,
#{max_size} ) )
        end
      }
      consumer_class.class_eval code
  end

BTW it seems odd to use the #initialize method of ImageBob to do this.

HTH,
T.
47fb897113ebddae565f2f4b9f45ca1d?d=identicon&s=25 johanatan <zjll9@imail.etsu.edu> <zjll9@imail.etsu (Guest)
on 2005-12-05 02:44
transfire wrote:
> If you don't mind while I'm at this I'm going to touch up the code to
> follow ruby conventions.

I don't mind at all.  I'm new to ruby so I haven't picked up on the
extensions yet. :)

>
>   def initialize( attr_and_sizes_hash, consumer_class )
>     attr_and_sizes_hash.each {|attr_name, max_size|
>       code = %{
>         def #{attr_name}=( file )
>           write_attribute( '#{attr_name}', ImageBlob.getBlob( file,
> #{max_size} ) )
>         end
>       }
>       consumer_class.class_eval code
>   end
>

I didn't try class_eval.  Did you test this or is it just a theory? :)
Seemed like regular eval and extend should work.

> BTW it seems odd to use the #initialize method of ImageBob to do this.

It is odd, but the ImageBlob class contains only one class method (i.e.,
static method) and no data members, so no actual memory should be
defined for it.  I suppose it could have contained two class methods
instead of using initialize (that is better so I'll change that).  At
first, I was trying to store a ptr to the ImageBlob instance in the
consumer class but realized it wasn't necessary.

Much thanks for the answers.
47fb897113ebddae565f2f4b9f45ca1d?d=identicon&s=25 johanatan <zjll9@imail.etsu.edu> <zjll9@imail.etsu (Guest)
on 2005-12-05 02:53
Ok.  The class is ready for consumption. :)  Here it is:

require 'RMagick'
include Magick

class ImageBlob

  def ImageBlob.inject_attrib_assign_methods( attr_and_sizes_hash,
consumer_class )
    attr_and_sizes_hash.each {|attr_name, max_size|
      code = %{
        def #{attr_name}=( file )
          write_attribute( '#{attr_name}', ImageBlob.getBlob( file,
#{max_size} ))
        end
      }
      consumer_class.class_eval code }
  end

  def ImageBlob.getBlob( file, max_image_size )
    begin
      img = Image.from_blob( file.read ).first
      if not img
        raise
      end

      img.format = "JPG"

      if img.rows > max_image_size or img.columns > max_image_size
        if img.rows > img.columns
          factor = max_image_size / img.rows.to_f
        else
          factor = max_image_size / img.columns.to_f
        end

        img = img.scale( factor )
      end

      retVal = img.to_blob
      GC.start
      return retVal
    rescue
      return nil
    end
  end
end
47fb897113ebddae565f2f4b9f45ca1d?d=identicon&s=25 johanatan <zjll9@imail.etsu.edu> <zjll9@imail.etsu (Guest)
on 2005-12-05 02:54
An example of using this is:

in a class definition:
----------------------
ImageBlob.inject_attrib_assign_methods( { "image" => 225,
"thumbnailImage" => 125 }, self )
45196398e9685000d195ec626d477f0e?d=identicon&s=25 transfire (Guest)
on 2005-12-05 03:26
(Received via mailing list)
johanatan <zjll9@imail.etsu.edu> <zjll9@imail.etsu.edu> wrote:
> transfire wrote:
> > If you don't mind while I'm at this I'm going to touch up the code to
> > follow ruby conventions.
>
> I don't mind at all.  I'm new to ruby so I haven't picked up on the
> extensions yet. :)

Understandable. As you've noticed Matz prefers underscores and
lowercase over camelcase for methd names, so that's become the general
convention. There's alos a tendency to get them as small as possible
while still being human readable/self-documenting.

> >       consumer_class.class_eval code
> >   end
> >
>
> I didn't try class_eval.  Did you test this or is it just a theory? :)
> Seemed like regular eval and extend should work.

I didn't test, but I've used it enough times to know that the way to go
about it (even I made a booboo in my code) You'll notice David used it
in his variation too.

> > BTW it seems odd to use the #initialize method of ImageBob to do this.
>
> It is odd, but the ImageBlob class contains only one class method (i.e.,
> static method) and no data members, so no actual memory should be
> defined for it.  I suppose it could have contained two class methods
> instead of using initialize (that is better so I'll change that).  At
> first, I was trying to store a ptr to the ImageBlob instance in the
> consumer class but realized it wasn't necessary.

If ImagaBob is not instantiable then a module would be better than a
class.

> Much thanks for the answers.

No problemo.

T.
45196398e9685000d195ec626d477f0e?d=identicon&s=25 transfire (Guest)
on 2005-12-05 03:38
(Received via mailing list)
Couple suggestions:

  def ImageBlob.inject_attrib_assign_methods

to

  def self.inject_accessors

Using 'self' is more robust. Also in Ruby attribute methods are
generally refered to as accessors.

  def ImageBlob.getBlob( file, max_image_size )
    begin
      img = Image.from_blob( file.read ).first
      if not img
        raise
      end

to

  def self.get_blob( file, max_image_size )
    begin
      img = Image.from_blob( file.read ).first
      return nil if not img

Don't use camelcase (unless you're passionate about it) and there's no
need to raise if the rescue clause is just going ot return nil anyway.

T.
47fb897113ebddae565f2f4b9f45ca1d?d=identicon&s=25 Jonathan <zjll9@imail.etsu.edu> <zjll9@imail.etsu. (Guest)
on 2005-12-06 02:52
transfire wrote:
> Couple suggestions:
>
>   def ImageBlob.inject_attrib_assign_methods
>
> to
>
>   def self.inject_accessors
>
> Using 'self' is more robust. Also in Ruby attribute methods are
> generally refered to as accessors.
>

I agree with the name change.  However, the class isn't instantiable, so
using self won't work.  I will change this to a module though.  (you can
call methods of a module without mixing it in right?)

>   def ImageBlob.getBlob( file, max_image_size )
>     begin
>       img = Image.from_blob( file.read ).first
>       if not img
>         raise
>       end
>
> to
>
>   def self.get_blob( file, max_image_size )
>     begin
>       img = Image.from_blob( file.read ).first
>       return nil if not img
>
> Don't use camelcase (unless you're passionate about it) and there's no
> need to raise if the rescue clause is just going ot return nil anyway.

Thanks for point that out.  I overlooked getBlob.

--Jonathan
47fb897113ebddae565f2f4b9f45ca1d?d=identicon&s=25 Jonathan <zjll9@imail.etsu.edu> <zjll9@imail.etsu. (Guest)
on 2005-12-06 02:56
Here's the updated code:

require 'RMagick'
include Magick

module ImageBlob

  def ImageBlob.inject_assigners( attr_and_sizes_hash,
consumer_class )
    attr_and_sizes_hash.each {|attr_name, max_size|
      code = %{
        def #{attr_name}=( file )
          write_attribute( '#{attr_name}', ImageBlob.get_blob( file,
#{max_size} ))
        end
      }
      consumer_class.class_eval code }
  end

  def ImageBlob.get_blob( file, max_image_size )
    begin
      img = Image.from_blob( file.read ).first
      return nil if not img

      img.format = "JPG"

      if img.rows > max_image_size or img.columns > max_image_size
        if img.rows > img.columns
          factor = max_image_size / img.rows.to_f
        else
          factor = max_image_size / img.columns.to_f
        end

        img = img.scale( factor )
      end

      ret_val = img.to_blob
      GC.start
      return ret_val
    rescue
      return nil
    end
  end
end
47fb897113ebddae565f2f4b9f45ca1d?d=identicon&s=25 Jonathan <zjll9@imail.etsu.edu> <zjll9@imail.etsu. (Guest)
on 2005-12-06 03:01
>
> I agree with the name change.  However, the class isn't instantiable, so
> using self won't work.  I will change this to a module though.  (you can
> call methods of a module without mixing it in right?)

Oops.  I guess 'self' in that context refers to the module or class??
Yea, that would be more robust (or at least more consistent with
write-once.  changing the name of a class or module would require
changing all static method names (are these called class methods in
ruby??) unless self is used.  Is that the reason you think it's more
robust or was it something else?
47fb897113ebddae565f2f4b9f45ca1d?d=identicon&s=25 Jonathan <zjll9@imail.etsu.edu> <zjll9@imail.etsu. (Guest)
on 2005-12-06 03:04
transfire wrote:
> Using 'self' is more robust. Also in Ruby attribute methods are
> generally refered to as accessors.
>

I've always heard 'accessor' refers to a get_prop method and 'assigner'
refers to a set_prop method.  Does accessor refer to both in Ruby?
45196398e9685000d195ec626d477f0e?d=identicon&s=25 transfire (Guest)
on 2005-12-06 03:20
(Received via mailing list)
> I've always heard 'accessor' refers to a get_prop method and 'assigner'
> refers to a set_prop method.  Does accessor refer to both in Ruby?

Yes, becuase of the common convenience method:

  attr_accessor :a

which creates both a "reader" and a "writer", which are the terms Ruby
generally uses. What I mean by *convenience* method is that the above
is simply a shortcut for doing:

  def a
    @a
  end

  def a=(x)
    @a = x
  end

And is the same as doing

  attr_reader :a
  attr_writer :a

T.
45196398e9685000d195ec626d477f0e?d=identicon&s=25 transfire (Guest)
on 2005-12-06 03:24
(Received via mailing list)
Jonathan <zjll9@imail.etsu.edu> <zjll9@imail.etsu. wrote:
> robust or was it something else?
Nope, that's it exactly.

T.
45196398e9685000d195ec626d477f0e?d=identicon&s=25 transfire (Guest)
on 2005-12-06 03:57
(Received via mailing list)
>However, the class isn't instantiable, so using self won't work.

Sure it will. 'self' just refers to the current context, in either case
whether class or module that's what it is. So it should work fine.

> (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.
82e62c756d89bc6fa0a0a2d7f2b1e617?d=identicon&s=25 rosco (Guest)
on 2005-12-06 04:01
(Received via mailing list)
On Tue, 06 Dec 2005 02:10:51 -0000, Trans <transfire@gmail.com> wrote:

>> ... singleton methods, or adhoc methods (my new prefered
> term).

I know I'm new, but humour me if you will ?

Firstly, what's wrong with 'singleton'? It seems to me that it fits
well,
and makes the usage obvious to the reader (well, me, but I assume others
too?). Secondly, 'Ad-hoc' seems to be a really odd choice to me. I am
aware that it can be taken to mean 'Specific to a given problem', but it
is also defined along the lines of 'impromtu', 'temporary' or
'disorganized'. Science uses it to mean a quick fix for a flawed theory.
Upon seeing the word ad-hoc I tend to imagine 'jury rigged' - stuck
together with duct tape to last us out the storm.

Indeed, someone given to 'adhocism' (IMHO an awful word) exhibits 'the
tendency to use temporary, provisional, or improvised methods to deal
with
a particular problem'. I wouldn't want my solutions to be seen as
'temporary' or 'provisional', whether tailor-made or otherwise.

I'm sure this is an ongoing debate, and I don't want to tread on any
beliefs, but I just thought I'd offer a perspective from a fresh pair of
eyes. Is there a serious movement to replace 'singleton'?
C1bcb559f87f356698cfad9f6d630235?d=identicon&s=25 hal9000 (Guest)
on 2005-12-06 04:17
(Received via mailing list)
Ross Bamford wrote:
>
> I know I'm new, but humour me if you will ?
>
> Firstly, what's wrong with 'singleton'?

[snippage]

It doesn't really bother me. But there is some confusion with
the Singleton pattern, and with other similar usages.

> I'm sure this is an ongoing debate, and I don't want to tread on any
> beliefs, but I just thought I'd offer a perspective from a fresh pair
> of  eyes. Is there a serious movement to replace 'singleton'?

Some people want to change it, I think. If it must be changed, I
would favor something like "singular class" (and I agree with your
assessment of "ad hoc"). Some have suggested "eigenclass" -- and I
admit this is a cool-sounding word, reminding me of my math and physics
(and German) in college. But I can't really advocate it seriously.


Hal
47fb897113ebddae565f2f4b9f45ca1d?d=identicon&s=25 Jonathan <zjll9@imail.etsu.edu> <zjll9@imail.etsu. (Guest)
on 2005-12-06 05:03
> It doesn't really bother me. But there is some confusion with
> the Singleton pattern, and with other similar usages.
>
>> I'm sure this is an ongoing debate, and I don't want to tread on any
>> beliefs, but I just thought I'd offer a perspective from a fresh pair
>> of  eyes. Is there a serious movement to replace 'singleton'?
>
> Some people want to change it, I think. If it must be changed, I
> would favor something like "singular class" (and I agree with your
> assessment of "ad hoc"). Some have suggested "eigenclass" -- and I
> admit this is a cool-sounding word, reminding me of my math and physics
> (and German) in college. But I can't really advocate it seriously.

Hal,

I think transfire (and rosco) were referring to singleton methods, not
classes.  And, actually I totally agree with the points made by rosco.
'Ad hoc' has too many negative connotations and singleton has a fairly
unambiguous meaning.

A singleton class should appear to the consumer as a regular class, but
under the skin always return the same instance.  How is this
accomplished in Ruby?  It couldn't be done in initialize, could it
(because initialize doesn't actually return an instance)?

--Jonathan
45196398e9685000d195ec626d477f0e?d=identicon&s=25 transfire (Guest)
on 2005-12-06 05:26
(Received via mailing list)
Ross Bamford wrote:
> On Tue, 06 Dec 2005 02:10:51 -0000, Trans <transfire@gmail.com> wrote:
>
> >> ... singleton methods, or adhoc methods (my new prefered
> > term).
>
> I know I'm new, but humour me if you will ?
>
> Firstly, what's wrong with 'singleton'? It seems to me that it fits well,
> and makes the usage obvious to the reader (well, me, but I assume others
> too?).

There has been much discussion about this. The problem with the term
singleton is that it clashes with singleton design pattern, which is
something different altogether. B/c of this much discussion has been
given to finding a better term.

Now, The original term I believe was "virtual class", indeed you will
still find an error or two in core that uses that phrase. I'm not sure
you will find the term "singleton" anywhere in the source though. Also
the the term "metaclass" was used when the context is of a class' or
module's singleton class.  But metaclass fell out of favor --I think
b/c matz said he didn't like it. So "singleton" came along to sort of
fill the void, not so much for its particular merits, but more for the
lack of something better. Also I point out we have other terms that can
cause confusion, although they too refer to the same thing just in a
particular usage, namely "class methods" and "module methods".

About a year ago, I was having to decide what term to use in Facets, I
included the ususal fair but wan't happy about having to have so many
methods all for the same thing. So I tried to find a more suitable term
that we all could generally agree on. I've tried out a few ideas, but
none of them really worked. Around that time _why the lucky stiff came
up with the term "eigenclass", and that has had some sticking power, no
doubt in part due to the ingenius humor he can bring to things. I think
it a fairly good term, and I think we should keep using it and even get
a bit more serious about it, tough obviously it still lacks in certain
respects. I had all but given up on finding a better term until I
accidently came acrosss "ad hoc". And I've actually been surprised and
delighted at just how well that term works.

> Secondly, 'Ad-hoc' seems to be a really odd choice to me. I am
> aware that it can be taken to mean 'Specific to a given problem', but it
> is also defined along the lines of 'impromtu', 'temporary' or
> 'disorganized'. Science uses it to mean a quick fix for a flawed theory.
> Upon seeing the word ad-hoc I tend to imagine 'jury rigged' - stuck
> together with duct tape to last us out the storm.

You see that's not the actual definition of the term. That's more of
the vague understanding one gathers from not actually knowing the
meaning. Although that vague idea has become widespread enough to be
acknolwedged, it is still a secondary usage. I understand where you're
coming from though, b/c I thought much the same way until I had used
the word inproperly and my Grandmother corrected me. I wasn't so sure,
so we looked it up in the dictionary and sure enough she was right. The
definition is quite clear. From Websters (and others):

  Main Entry: 1ad hoc
  Pronunciation: 'ad-'häk, -'hOk; 'äd-'hOk
  Function: adverb
  Etymology: Latin, for this
  : for the particular end or case at hand without consideration of
wider application

That's how I realized the term would make a good fit.

> Indeed, someone given to 'adhocism' (IMHO an awful word)
> exhibits 'the tendency to use temporary, provisional, or improvised methods to deal with
> a particular problem'. I wouldn't want my solutions to be seen as
> 'temporary' or 'provisional', whether tailor-made or otherwise.

Yep, "adhocism" is a bad term, it's fairly recent, hardly known, and
really a misuse of the term adhoc. One gets this shade of meaning from
applying the term to a particular *moment* --its the purpose itself
that is temporary or provisional, not the "for" of it.

> I'm sure this is an ongoing debate, and I don't want to tread on any
> beliefs, but I just thought I'd offer a perspective from a fresh pair of
> eyes. Is there a serious movement to replace 'singleton'?

I did a survey once and people's opinions are all over the map. I
personaly would like to see a solid term. I think 'adhoc' works well
becuase it is small, ponient and has the added advantage (which none of
the other choices have) of being an adverb, so it has very flexible
usage. I guess my end preference to all this is that we migrate to the
terms 'adhoc' and 'eigenclass' as is suitable. But I think this will
happen naturally if the terms work.

T.
45196398e9685000d195ec626d477f0e?d=identicon&s=25 transfire (Guest)
on 2005-12-06 05:34
(Received via mailing list)
> 'Ad hoc' has too many negative connotations and singleton has a fairly
> unambiguous meaning.

I felt the same way at first, until I started using it, keeping in mind
the strict definition --even the Latin definition: *for this*.

T.
1fba4539b6cafe2e60a2916fa184fc2f?d=identicon&s=25 dblack (Guest)
on 2005-12-06 07:00
(Received via mailing list)
Hi --

On Tue, 6 Dec 2005, Trans wrote:

> About a year ago, I was having to decide what term to use in Facets, I
> included the ususal fair but wan't happy about having to have so many
> methods all for the same thing. So I tried to find a more suitable term
> that we all could generally agree on. I've tried out a few ideas, but
> none of them really worked. Around that time _why the lucky stiff came
> up with the term "eigenclass", and that has had some sticking power, no
> doubt in part due to the ingenius humor he can bring to things. I think
> it a fairly good term, and I think we should keep using it and even get
> a bit more serious about it, tough obviously it still lacks in certain
> respects.

This subject used to be approached in the spirit of making suggestions
to
Matz, to help him in the process of coming up with a good replacement
term
for "singleton class" if he decides to replace it.  For some reason it's
turned into people not only coining terms but actually using them
publicly
as drop-in replacements, unremarked upon, for "singleton class."  The
result is that, de facto, there's no term any more, when there used to
be
a perfectly serviceable term.  Instead there's a kind of smeared rainbow
of terms, and a lot of meta-explanations about why there's a smeared
rainbow instead of a term.

It's regrettable that the thing singled out for this strange treatment
is
something that's often quite difficult for Ruby learners to understand
anyway.  Having to learn not only the mechanics of singleton classes,
but
also a bunch of Ruby community lore about who uses what term, just so
that
one can understand what various people are saying, seems to me to be
pretty tiresome.

Oh well -- obviously the shipped has sailed on this.  I just hope that
if
Matz does make some kind of decision about it, people will actually pay
attention to it.


David

__
David A. Black
dblack@wobblini.net

"Ruby for Rails", forthcoming from Manning Publications, April 2006!
82e62c756d89bc6fa0a0a2d7f2b1e617?d=identicon&s=25 rosco (Guest)
on 2005-12-06 10:03
(Received via mailing list)
On Tue, 06 Dec 2005 03:14:12 -0000, Hal Fulton
<hal9000@hypermetrics.com>
wrote:

> Ross Bamford wrote:
>>  I know I'm new, but humour me if you will ?
>>  Firstly, what's wrong with 'singleton'?
>
> [snippage]
>
> It doesn't really bother me. But there is some confusion with
> the Singleton pattern, and with other similar usages.
>

Now I've spent some time with the lingo, I'm not especially bothered
either. But when I first started reading Ruby it was confusing enough to
make me think twice about learning ocaml instead. I see the confusion
with
Singleton, but to be honest it felt 'right-ish' to me nevertheless. I
was
searching around trying to find out what an Eigenclass was, and when I
found it described as 'singleton class' that set me on the right road.
It
doesn't exactly fit, but it's not a million miles away either.

>> I'm sure this is an ongoing debate, and I don't want to tread on any
>> beliefs, but I just thought I'd offer a perspective from a fresh pair
>> of  eyes. Is there a serious movement to replace 'singleton'?
>
> Some people want to change it, I think. If it must be changed, I
> would favor something like "singular class" (and I agree with your
> assessment of "ad hoc"). Some have suggested "eigenclass" -- and I
> admit this is a cool-sounding word, reminding me of my math and physics
> (and German) in college. But I can't really advocate it seriously.
>

Eigenclass is definitely l337er ;) Singular class could work I think,
for
the reason I mentioned above - it's the idea that it applies to a single
instance. Metaclass also seems to fit, but again I think the meaning of
meta is being gradually relaxed by popular usage (much like ad-hoc I
guess, but the other way around).

Whatever happens I hope the powers that be bear in mind that Ruby is
becoming ever more widespread, so whatever ends up being chosen needs to
in some way lead the newbie to the idea of a class that applies to an
object (instance class? Seems like a contradiction in terms...)
82e62c756d89bc6fa0a0a2d7f2b1e617?d=identicon&s=25 rosco (Guest)
on 2005-12-06 10:44
(Received via mailing list)
On Tue, 06 Dec 2005 04:19:03 -0000, Trans <transfire@gmail.com> wrote:

>> and makes the usage obvious to the reader (well, me, but I assume others
>> too?).
>
> There has been much discussion about this. The problem with the term
> singleton is that it clashes with singleton design pattern, which is
> something different altogether. B/c of this much discussion has been
> given to finding a better term.
>

I had the feeling this was something of an ongoing issue from the
discussion I've seen here :)

>
I think Metaclass could have been a contender, but then again it too
could
mean a variety of things I suppose. Absolutely agree about other terms
causing confusion, but I've not seen that many that seemed _intended_ to
cause confusion, like eigenclass (I'm not saying that is the case, just
that it appeared that way from a rank newbie perspective).

> acknolwedged, it is still a secondary usage. I understand where you're
> wider application
>
> That's how I realized the term would make a good fit.
>

I probably got that the wrong way around at 2am :) You're right of
course
that ad-hoc's primary definition relates to a vertical solution, but
still
I think that the secondary definition has been around for long enough
(even if based on popular misuse/misconception), and in fact probably
carries more weight in most people's minds

If "Car manufacturer X has an ad-hoc safety testing system", would you
buy
the '06 model 'X' Voyager? Even if it means they put their test rig
together specifically to test safety of that model, the negative
connotations of the word kind of bury that in the popular view, I think.

> happen naturally if the terms work.
>

Definitely agree it's important to find a solid term, and stick to it,
and
I can see why you like these terms, but I think if Ruby is going to
continue going from strength to strength (and I hope it will!) something
less esoteric should be chosen (no, I don't know what. It's easy to
criticise but when it comes to suggesting alternatives ... ;) ).

Perhaps it's something that only decisive action by the powers that be
in
Ruby can really settle...
45196398e9685000d195ec626d477f0e?d=identicon&s=25 transfire (Guest)
on 2005-12-06 14:00
(Received via mailing list)
David A. Black wrote:
>
> It's regrettable that the thing singled out for this strange treatment is
> something that's often quite difficult for Ruby learners to understand
> anyway.  Having to learn not only the mechanics of singleton classes, but
> also a bunch of Ruby community lore about who uses what term, just so that
> one can understand what various people are saying, seems to me to be
> pretty tiresome.
>
> Oh well -- obviously the shipped has sailed on this.  I just hope that if
> Matz does make some kind of decision about it, people will actually pay
> attention to it.

Well, I think matz has never made a fird decision on it, and it seems
has prefered to let the ciommunity sort it out, as is evidence by the
fact the the source still referes to "virtual class", another perfectly
servicable term but one I think you yourself objected too b/c of it's
overlap with virtual classes in c.

T.
45196398e9685000d195ec626d477f0e?d=identicon&s=25 transfire (Guest)
on 2005-12-06 14:04
(Received via mailing list)
s/fird/firm/
1fba4539b6cafe2e60a2916fa184fc2f?d=identicon&s=25 dblack (Guest)
on 2005-12-06 15:26
(Received via mailing list)
Hi --

On Tue, 6 Dec 2005, Trans wrote:

> > of terms, and a lot of meta-explanations about why there's a smeared
> > Matz does make some kind of decision about it, people will actually pay
> > attention to it.
>
> Well, I think matz has never made a fird decision on it, and it seems
> has prefered to let the ciommunity sort it out, as is evidence by the
> fact the the source still referes to "virtual class", another perfectly
> servicable term but one I think you yourself objected too b/c of it's
> overlap with virtual classes in c.

I don't know what you mean about Matz not having made a firm decision.
Was he under some deadline, imposed by you?  Did he say, "Call singleton
classes lots of different things, when discussing Ruby with newcomers,
and
let's have some kind of vulgar pseudo-Darwinian contest to see whose
usage
outnumbers everyone else's"?

Or did he lose his right to make a decision at all because he hasn't
cleansed the source of the term "virtual class" and you caught him at
it?
(Like a game of "Simon Says" -- "You said 'virtual class' -- you're
out!")
Does every inconsistency or ambiguity in the source indicate something
that Matz "prefers to let the community sort out"?

These are rhetorical questions; your answers to them are actually
already
present in what you've written.  My main goal is to suggest to others
that
the growth of Ruby does not *have* to mean a growing disconnect between
the community and Matz, or the community and a set of traditional
practices (including the practice of discussing things with Matz and
taking an interest in what he says).  What we've got *can* scale, with a
little care and attention.


David
__
David A. Black
dblack@wobblini.net

"Ruby for Rails", forthcoming from Manning Publications, April 2006!
45196398e9685000d195ec626d477f0e?d=identicon&s=25 transfire (Guest)
on 2005-12-06 19:11
(Received via mailing list)
Okay David, its obvious you're getting upset. Though you say the
questions are rhetorical, they nonetheless have a very simple answer:

  I ASKED MATZ AND HE HAD NO ANSWER.

What am I suppose to think then? Don't you recall the conversation? It
wan't that long ago. In fact I think it was in that thread _why first
came up with the term 'eigenclass', or at least the first I had heard
of it. And at the tiem I was suggesting the term "special class".

So I dont know where you gettting this disconnect between matz and
community. I asked matz, Matz has participated, but obviously he's not
sure either or he would have made it clear. If Matz wanted to, he could
easily step in at anytime and say "Hey, enough. This is what we call
it". Right? Maybe he will eventually, but in the mean time I don't see
anything wrong with trying out alternatives. We all know that the term
'singleton' has a semantic overlap problem, as is once again
demonstrated by Johnathans post to this thread. Go back and read it. So
lets keep trying out the possibilites. If for instance you really like
"own" then use it see if it sticks. Short of Matz making an edict, I
don't see how else it can get worked out.

T.
1fba4539b6cafe2e60a2916fa184fc2f?d=identicon&s=25 dblack (Guest)
on 2005-12-06 19:52
(Received via mailing list)
Hi --

On Wed, 7 Dec 2005, Trans wrote:

> So I dont know where you gettting this disconnect between matz and
> community. I asked matz, Matz has participated, but obviously he's not
> sure either or he would have made it clear. If Matz wanted to, he could
> easily step in at anytime and say "Hey, enough. This is what we call
> it". Right? Maybe he will eventually, but in the mean time I don't see
> anything wrong with trying out alternatives. We all know that the term
> 'singleton' has a semantic overlap problem, as is once again
> demonstrated by Johnathans post to this thread. Go back and read it. So
> lets keep trying out the possibilites. If for instance you really like
> "own" then use it see if it sticks. Short of Matz making an edict, I
> don't see how else it can get worked out.

I almost literally can't believe my answer to this isn't clear from what
I've already said, but in case not, the answer is: use the standard (if
sometimes problematic) term, and don't set deadlines for Matz.  To say
that Matz is "not sure", and that therefore all bets are off, just
because
he hasn't made a change, is wrong.

I don't *want* to go around talking about "own classes".  I don't *want*
to introduce coinages into Ruby discourse in the hope that people will
think they're conventional terms that other people will understand, when
they aren't.  "Trying out the possibilities" means muddying the waters
and
confusing newcomers.  I don't want to do that either, to the extent I
can
help it.


David
__
David A. Black
dblack@wobblini.net

"Ruby for Rails", forthcoming from Manning Publications, April 2006!
45196398e9685000d195ec626d477f0e?d=identicon&s=25 transfire (Guest)
on 2005-12-06 20:24
(Received via mailing list)
David A. Black wrote:
> > wan't that long ago. In fact I think it was in that thread _why first
> > demonstrated by Johnathans post to this thread. Go back and read it. So
> I don't *want* to go around talking about "own classes".  I don't *want*
> to introduce coinages into Ruby discourse in the hope that people will
> think they're conventional terms that other people will understand, when
> they aren't.  "Trying out the possibilities" means muddying the waters and
> confusing newcomers.  I don't want to do that either, to the extent I can
> help it.

Standards? Alright genius, why don't you use the the term "virtual
class" then? After all that's what it says in the source code -- and
you can't get any more standard than that. But I remember cleary you
going-on, "Please not virtual class!", and how terrible it was becuase
of it's sematic overlap with the kind in c. Well, I have the same
problem with singleton, and worse because both kinds exist in Ruby. I
never like using the term becuase I always feel like I need to put a
dang parenthecal explination after it. Why is your trouble more
important than the other?  --Indeed, on reflection, it seems that
people stopped using "virtual" b/c of your request. Hmmm...I wonder
what term they use in Japanese?

Anyway, I'm sorry there was all this fuss. The term adhoc works as a
general lingusitic modifier with the appropriate meaning, whether its
is a "standard" term or not, and I will use it as such --a
singleoton/eigen/meta/virtual class, whatever you call it, is very much
adhoc.

T.
1fba4539b6cafe2e60a2916fa184fc2f?d=identicon&s=25 dblack (Guest)
on 2005-12-06 20:45
(Received via mailing list)
Hi --

On Wed, 7 Dec 2005, Trans wrote:

> > >
> > > anything wrong with trying out alternatives. We all know that the term
> > he hasn't made a change, is wrong.
> you can't get any more standard than that. But I remember cleary you
> going-on, "Please not virtual class!", and how terrible it was becuase
> of it's sematic overlap with the kind in c.

My problem with virtual is that singleton classes aren't virtual.

> Well, I have the same problem with singleton, and worse because both
> kinds exist in Ruby. I never like using the term becuase I always feel
> like I need to put a dang parenthecal explination after it. Why is your
> trouble more important than the other?  --Indeed, on reflection, it
> seems that people stopped using "virtual" b/c of your request. Hmmm...I
> wonder what term they use in Japanese?

You're mixing up two things.  I have no problem with discussing the
merits
of all these terms.  As you say, I've been involved in these discussions
already, and I imagine I will continue to be.

What I don't like is jumping ship from the whole discussion process,
because Matz's supposed time-limit has expired (or whatever), and just
starting to use a term in the hope that it will "take".

> Anyway, I'm sorry there was all this fuss. The term adhoc works as a
> general lingusitic modifier with the appropriate meaning, whether its
> is a "standard" term or not, and I will use it as such --a
> singleoton/eigen/meta/virtual class, whatever you call it, is very much
> adhoc.

Singleton classes are also (one finds) "puzzling" to a lot of people.  I
would not like to see a sect of people saying that "every object has a
'puzzling class'".

There's got to be more to this than everyone coming up with an adjective
that he or she finds apt and using it.


David
__
David A. Black
dblack@wobblini.net

"Ruby for Rails", forthcoming from Manning Publications, April 2006!
47b1910084592eb77a032bc7d8d1a84e?d=identicon&s=25 vjoel (Guest)
on 2005-12-06 21:01
(Received via mailing list)
David A. Black wrote:

> There's got to be more to this than everyone coming up with an adjective
> that he or she finds apt and using it.

Maybe we should just call it the "double left angle bracket" class, as
long as that's the syntax for it ;)
E7559e558ececa67c40f452483b9ac8c?d=identicon&s=25 gwtmp01 (Guest)
on 2005-12-06 21:50
(Received via mailing list)
On Dec 6, 2005, at 2:42 PM, David A. Black wrote:
> You're mixing up two things.  I have no problem with discussing the
> merits
> of all these terms.  As you say, I've been involved in these
> discussions
> already, and I imagine I will continue to be.

Just for the record, IMHO:

virtual class:
    too much semantic overlap with C++ usage
    generally assumed to be associated with a *class* (not an
arbitrary object)

meta class:
    meta, as an adjective, is too vague
    generally assumed to be associated with a *class* (not an
arbitrary object)

singleton class:
    has the wrong semantic 'direction' (from class to object)
probably because:
    too much semantic overlap with the singleton pattern
    easily confused with the specific Singleton class in the standard
library

adhoc class:
    too many negative connotations despite the useful latin root

eigen class:
    has the right semantic 'direction' (from object to class)
    'eigen', as a prefix/adjective, has an clear meaning that matches
the
        semantics of (class <<self; self; end)
    long history of use in science, math, etc.
    it is easier to type object.eclass than (class <<object; self; end)


P.S.  I think one of the reasons we all still type (class <<object;
self; end)
is that the terminology for the concept isn't "solid" yet.  Until you
have
a solid, short, clear name it is pretty hard to add a standard method
to Object
that returns this 'thing' we are talking about.


Gary Wright
912c61d9da47754de7039f4271334a9f?d=identicon&s=25 mental (Guest)
on 2005-12-06 22:23
(Received via mailing list)
On Wed, 2005-12-07 at 04:42 +0900, David A. Black wrote:
> There's got to be more to this than everyone coming up with an adjective
> that he or she finds apt and using it.

I don't know, man.  Personally at this point I think we should stand
back and let natural selection do its thing.

-mental
1fba4539b6cafe2e60a2916fa184fc2f?d=identicon&s=25 dblack (Guest)
on 2005-12-06 22:35
(Received via mailing list)
Hi --

On Wed, 7 Dec 2005, MenTaLguY wrote:

> On Wed, 2005-12-07 at 04:42 +0900, David A. Black wrote:
> > There's got to be more to this than everyone coming up with an adjective
> > that he or she finds apt and using it.
>
> I don't know, man.  Personally at this point I think we should stand
> back and let natural selection do its thing.

Natural selection isn't connected to what we're talking about.  If you
mean we should ignore Matz, or find a way to coerce him into changing
his
terminology to match a bunch of Google searches -- while, meanwhile, a
lot
of newcomers to Ruby suffer because of how cool people think their names
for singleton classes are --  then I don't think you've got a sound or
respectful plan.


David
__
David A. Black
dblack@wobblini.net

"Ruby for Rails", forthcoming from Manning Publications, April 2006!
912c61d9da47754de7039f4271334a9f?d=identicon&s=25 mental (Guest)
on 2005-12-07 03:48
(Received via mailing list)
On Wed, 2005-12-07 at 06:32 +0900, David A. Black wrote:

> Natural selection isn't connected to what we're talking about.  If you
> mean we should ignore Matz, or find a way to coerce him into changing his
> terminology to match a bunch of Google searches

I think the disadvantages to the alternate terminology have been laid
out pretty clearly in this thread already.  People can make informed
decisions.

People are going to do what they want.  Neither you nor I (nor even
Matz, really) can control that.  Ruby is a living culture, with give and
take and evolving terminology.

> -- while, meanwhile, a lot of newcomers to Ruby suffer because of how
> cool people think their names for singleton classes are --  then I don't
> think you've got a sound or respectful plan.

Plan?  I'm just being realistic.

I've been close to a few ill-fated open source projects where the
prevailing attitude was that insisting on anything different from what
the project founder specifies is disrespectful and destructive.  That
attitude was deadly.

I've also been involved with a few projects (and cofounded one --
Inkscape) which were wildly successful, growing organically and
developing broad communities.  People were free to do their own thing,
and yet the project leaders were more respected.  Sometimes things do
get messy and confusing, but in my experience, even those messy and
confusing things work out in the end.

[ I'll leave it to others to decide which description better fits
Ruby. ]

I'm not a Taoist, but I think the notion of "striving-without-striving"
describes the necessary ethic nicely.  Relax.  This is not about control
or respect or disrespect or the Ultimate Fate of Ruby.

-mental
912c61d9da47754de7039f4271334a9f?d=identicon&s=25 mental (Guest)
on 2005-12-07 03:52
(Received via mailing list)
On Wed, 2005-12-07 at 11:18 +0900, MenTaLguY wrote:
> People were free to do their own thing, and yet the project
> leaders were more respected.

And, lest this be misconstrued, I don't think this is at all
incompatible with "benevolent dictator" roles.

The thing about benevolent dictators in the mode of e.g. Linus or Matz
is that there is is an essential freedom to their rule -- people follow
them not because they are forced or obligated to, but because they want
to.  That also means occasionally people won't.  Life goes on.

Matz fashions Ruby as he will, and people come to him because it is
good.

-mental
1fba4539b6cafe2e60a2916fa184fc2f?d=identicon&s=25 dblack (Guest)
on 2005-12-07 06:26
(Received via mailing list)
Hi --

On Wed, 7 Dec 2005, MenTaLguY wrote:

> On Wed, 2005-12-07 at 06:32 +0900, David A. Black wrote:
>
>> -- while, meanwhile, a lot of newcomers to Ruby suffer because of how
>> cool people think their names for singleton classes are --  then I don't
>> think you've got a sound or respectful plan.
>
> Plan?  I'm just being realistic.

Absolutely.  As I said in my second or so post about this, the ship
has sailed; it's obvious that, for whatever reason, singleton classes
*are* going to be called all sorts of different things.  I just think
it's too bad.

> I've been close to a few ill-fated open source projects where the
> prevailing attitude was that insisting on anything different from what
> the project founder specifies is disrespectful and destructive.  That
> attitude was deadly.

Again (last time?), I'm not saying that nothing should change -- just
that short-circuiting the discussion/decision process (which does
exist, and which has a track-record of working well for Ruby) is
short-sighted.

I could, for example, set up a web page that described Ruby as an
"item-oriented" language: everything is an "item", the class Object is
misnamed but Matz hasn't stepped in to correct so I have to, etc.  I
could probably manage to confuse a few newcomers.  But it wouldn't be
good.  (It's a hyperbolic example, but still.)

> I've also been involved with a few projects (and cofounded one --
> Inkscape) which were wildly successful, growing organically and
> developing broad communities.  People were free to do their own thing,
> and yet the project leaders were more respected.  Sometimes things do
> get messy and confusing, but in my experience, even those messy and
> confusing things work out in the end.
>
> [ I'll leave it to others to decide which description better fits
> Ruby. ]

I don't think it's necessary to pigeon-hole Ruby philosophically.  I
just wish people would let Matz decide what these classes should be
called.  (And remember that Matz's style of deciding *includes*
community input; by looking to Matz, I am not subscribing to some
philosophy of centralized power [believe me :-].)  It's really a
rather circumscribed point.

It's worth noting that a result of Matz's style of development, as
well as the contributions of the community, there actually aren't very
many things in the language that are vulnerable to this kind of
treatment.  Singleton classes seem to be the magnet for it.

> I'm not a Taoist, but I think the notion of "striving-without-striving"
> describes the necessary ethic nicely.  Relax.  This is not about control
> or respect or disrespect or the Ultimate Fate of Ruby.

Right -- it's about what to call singleton classes, and I wish people
would discuss it and then let Matz decide.  Maybe he'll decide that
the best thing is arbitrarily many terms, and then lots of people will
be a little bit happy :-)


David
--
David A. Black
dblack@wobblini.net

"Ruby for Rails", forthcoming from Manning Publications, April 2006!
0ec4920185b657a03edf01fff96b4e9b?d=identicon&s=25 matz (Guest)
on 2005-12-07 06:59
(Received via mailing list)
Hi,

In message "Re: injecting dynamic methods into a class"
    on Wed, 7 Dec 2005 03:07:34 +0900, "Trans" <transfire@gmail.com>
writes:

|Okay David, its obvious you're getting upset. Though you say the
|questions are rhetorical, they nonetheless have a very simple answer:
|
|  I ASKED MATZ AND HE HAD NO ANSWER.

Perhaps, I was drawn in the flood of ruby-talk mails (and spams).

I already abandoned the term "virtual class", and have removed the
term from the CVS head.  It still remains in 1.8 source just for
compatibility.  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.  I'm not sure yet that
"eigenclass" is the one, although it sounds cool.  I think we can wait
to see how it goes.

							matz.
45196398e9685000d195ec626d477f0e?d=identicon&s=25 transfire (Guest)
on 2005-12-07 07:19
(Received via mailing list)
Yukihiro Matsumoto wrote:
> Perhaps, I was drawn in the flood of ruby-talk mails (and spams).
Yes, that happens sometimes doesn't it. But I didn't mean that you
_didn't answer_  I recall your participation in those conversations. I
just meant that you didn't specify a certain term.

> I already abandoned the term "virtual class", and have removed the
> term from the CVS head.  It still remains in 1.8 source just for
> compatibility.  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.  I'm not sure yet that
> "eigenclass" is the one, although it sounds cool.  I think we can wait
> to see how it goes.

That's very clear. Thank you.

T.
Bc6d88907ce09158581fbb9b469a35a3?d=identicon&s=25 james_b (Guest)
on 2005-12-07 07:23
(Received via mailing list)
Trans wrote:
> Standards? Alright genius, why don't you use the the term "virtual
> class" then?


Can we keep this civil?

Disagree all you like with David and his line of thought; I'm stunned,
though, that anyone who has spent *any* time on this list would consider
insulting him or his reasoning ability.

It's just wrong, Trans.


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
45196398e9685000d195ec626d477f0e?d=identicon&s=25 transfire (Guest)
on 2005-12-07 08:16
(Received via mailing list)
I wasn't really insulting him. Just putting it back on him, so to
speak. Its a common phrase when someones feeding you contradictory
rhetoric, so you respond like that.

Irregadless, I do have some issues with some of the things David said
in this thread. He essentially put words in my mouth and even implied
that I was belittling Matz. Which isn't the case and isn't a very nice
way to discuss the issue. Sometimes I think David deserves a little
gusto in his direction. I don't know if you've noticed but he often
gives me a hard time in particular, and he can get pretty thick with
the rhetoric when he does. So I wouldn't get too worked up if I get a
little brazen with him. David and I have been here plenty of times
before. Haven't we? Probably will again. Seems like we're kind of polar
opposites at times. Anyway, I've come to expect it. So it is what it
is. I don't begrudge David despite our differences. And I don't expect
he does me either --well, at least I hope he's not stewing at home over
"that lousy no good trans" or something.

And just a little reminder. It was I who called for "Three Cheers for
David". I do appreciate what he's done, very much so. That doesn't mean
I'm always going to kiss his ars ;-)
Dce0999389d102f9a313af625375304c?d=identicon&s=25 dooby (Guest)
on 2005-12-07 08:45
(Received via mailing list)
MenTaLguY wrote:

> I don't know, man.  Personally at this point I think we should stand
> back and let natural selection do its thing.


But, IIUC, slaughter is frowned upon by civilised communities?

Quotes from:
http://use.perl.org/~Stevan/journal/27085
[ Saturday October 08, 2005 ]

"... shows how class-methods can be implemented using ruby-style
  eigenclasses (or singleton-methods as they are also called)."


  --  Well, well.  We're always the last to know  ;(


"Using the eigenclasses results in a very normalized method dispatch
 mechanism where instance method and class method dispatch are exactly
the same. What else can I say about that but ruby++."


   ^ ^
   @ @
    |
   {-}



daz
2cf6d8e639314abd751f83a72e9a2ac5?d=identicon&s=25 martindemello (Guest)
on 2005-12-07 12:54
(Received via mailing list)
David A. Black <dblack@wobblini.net> wrote:
>
> Natural selection isn't connected to what we're talking about.  If you
> mean we should ignore Matz, or find a way to coerce him into changing his
> terminology to match a bunch of Google searches -- while, meanwhile, a lot
> of newcomers to Ruby suffer because of how cool people think their names
> for singleton classes are --  then I don't think you've got a sound or
> respectful plan.

Note that the language itself doesn't call it *anything*. Indeed, there
isn't even an accessor for it, short of opening up its scope and
returning 'self'. So this is not equivalent to, say, suddenly deciding
to call Hashes Dictionaries instead - indeed, it's more a jargon issue
than a ruby-the-language one. Sort of akin to <=> coming to be called
the spaceship operator, or #! the shebang line.

martin
1fba4539b6cafe2e60a2916fa184fc2f?d=identicon&s=25 dblack (Guest)
on 2005-12-07 14:32
(Received via mailing list)
Hi --

On Wed, 7 Dec 2005, Martin DeMello wrote:

> isn't even an accessor for it, short of opening up its scope and
> returning 'self'.

I think that might change, though (I hope), once a long-term decision
is reached about the name and for that matter the implementation (if
it changes).

> So this is not equivalent to, say, suddenly deciding
> to call Hashes Dictionaries instead - indeed, it's more a jargon issue
> than a ruby-the-language one. Sort of akin to <=> coming to be called
> the spaceship operator, or #! the shebang line.

Not quite:

   ruby -ve 'class << 3; end'
   ruby 1.9.0 (2005-05-20) [i686-linux]
   -e:1: no singleton class for Fixnum (TypeError)

:-)  Also, with Matz discussing it so much, I'd put it in the category
of having official-name status.

But I know what you mean about jargon.  Just as people call objects
"underlying thingies" and so forth, there's no particular reason for
people not to use a term like "own class" or "eigenclass" (or "class a
soi", if they want to translate it into yet another language :-)
descriptively.  It's just that the burgeoning usage and positioning of
some of these terms have been unfortunate, in relation to the process
already underway.


David

--
David A. Black
dblack@wobblini.net

"Ruby for Rails", forthcoming from Manning Publications, April 2006!
912c61d9da47754de7039f4271334a9f?d=identicon&s=25 mental (Guest)
on 2005-12-07 16:18
(Received via mailing list)
On Wed, 2005-12-07 at 14:23 +0900, dblack@wobblini.net wrote:
> I don't think it's necessary to pigeon-hole Ruby philosophically.

I mainly intended to raise the question of whether bringing social
obligation into the discussion that way was really appropriate.  It
tends to be poisonous in technical forums.

> It's worth noting that a result of Matz's style of development, as
> well as the contributions of the community, there actually aren't very
> many things in the language that are vulnerable to this kind of
> treatment.  Singleton classes seem to be the magnet for it.

There are two reasons for this:  one, the name is one of the few aspects
of Ruby which people are fairly consistently unhappy with, and secondly,
it's an issue of human linguistics rather than of the programming
language.

I think we should expect an issue of human language to be resolved in
the fashion natural to it, rather than the more "up-front" and
centralized fashion typical for programming language issues.

(Of course, as noted elsewhere, I am a staunch linguistic descriptivist.
So perhaps that colors my thinking.)

> > I'm not a Taoist, but I think the notion of "striving-without-striving"
> > describes the necessary ethic nicely.  Relax.  This is not about control
> > or respect or disrespect or the Ultimate Fate of Ruby.
>
> Right -- it's about what to call singleton classes, and I wish people
> would discuss it and then let Matz decide.

I think that's what people are doing, basically.  That discussion is
simply going to be accomplished a bit differently than it would be for a
feature of the programming language itself.  The negotiation of new
human vocabulary involves trying alternatives in the real world and
seeing what sticks.

Based on Matz's most recent post, it sounds like that's what he's
waiting for too.

-mental
4b174722d1b1a4bbd9672e1ab50c30a9?d=identicon&s=25 leavengood (Guest)
on 2005-12-07 18:20
(Received via mailing list)
Here we go again with the endless discussion threads. I guess most of
you know my feelings on these threads based on a post not too long
ago, but I can't help but be sucked into this one too.

Firstly, in general I agree with David that we are on a slippery slope
with everyone using their own favorite singleton class synonym. For
that matter I'll bring my own favorite, shadow class, back into the
fray and muddy the waters more. All these terms will definitely
confuse newcomers and possibly even old hats, and it is sort of
annoying having to "translate" all the time.

But at the same time, I'm not sure how else these terms can be tested
out without actually using them. It seems Matz is sort of just waiting
and seeing what happens, which isn't a bad philosophy, but can
certainly result in some impatience and certain people trying to
impose their own standards on other people.

So with that wishy-washy essay out of the way, let me conclude with
some advice for Trans: I'm not sure if you realize it, but at least
from my perspective (and I'm sure others), I see you as some kind of
Ruby traitor, trying to subvert it from within. I would say "rebel",
but I don't think that conveys enough negativity. Every week it seems
like there is some thread spawned by you discussing the merits of some
massive change to Ruby. While in general this may not be a bad thing,
with the frequency I see it I can't help but automatically dismiss
much of what you say. Even a lot of the good work you have done on
Facets or Nano or Mega or Calibre or whatever it is called can be
dismissed because of the name changes and disorganization I've just
indicated. As harsh as this paragraph is, I don't mean it as a "screw
you Trans" type of thing, just an indication that is how at least one
person percieves you, and for most people, perception is reality.

Ryan
45196398e9685000d195ec626d477f0e?d=identicon&s=25 transfire (Guest)
on 2005-12-07 19:09
(Received via mailing list)
A Ruby TRAITOR? Because I offer up opinions, options and interesting
new ideas that arn't status quo?

Ah forget it. It aint worth it any more. You win Ryan. I repent.

  Adhoc
  Module method inheritance
  Core versioning support
  AOP Cuts
  Using core for tech discussions
  Perfecting the organization of Facets/Calibre
  Yes, the list goes on....

But all terrible terrible things! How evil I am for even mentioning
them, let alone actually trying to do them. Ugh, what a turncoat I have
been, an enemy of the Ruby state! Down witht he evil trans. Kill him.
KILL HIM!!!
4b174722d1b1a4bbd9672e1ab50c30a9?d=identicon&s=25 leavengood (Guest)
on 2005-12-07 19:34
(Received via mailing list)
ROFL. OK maybe traitor was a bit too dramatic. But this response was
worth it. ;)

Let's just try to find the middle ground between generally useful Ruby
changes and changes just because someone thinks they are cool.

Just so you know since I've been so "anti-Trans" in the past I plan to
look over Calibre and write about some of the gems (pun-intended) in
there.

Ryan
5befe95e6648daec3dd5728cd36602d0?d=identicon&s=25 bob.news (Guest)
on 2005-12-07 19:50
(Received via mailing list)
Ryan Leavengood <leavengood@gmail.com> wrote:

> Firstly, in general I agree with David that we are on a slippery slope
> with everyone using their own favorite singleton class synonym. For
> that matter I'll bring my own favorite, shadow class, back into the
> fray and muddy the waters more. All these terms will definitely
> confuse newcomers and possibly even old hats, and it is sort of
> annoying having to "translate" all the time.

You just made a case for sticking to "singleton class". :-))  I for my
part
stick with the old fashioned but well established term.  My 0.02EUR...

Kind regards

    robert
1fba4539b6cafe2e60a2916fa184fc2f?d=identicon&s=25 dblack (Guest)
on 2005-12-07 20:06
(Received via mailing list)
Hi --

On Thu, 8 Dec 2005, MenTaLguY wrote:

>> Right -- it's about what to call singleton classes, and I wish people
>> would discuss it and then let Matz decide.
>
> I think that's what people are doing, basically.  That discussion is
> simply going to be accomplished a bit differently than it would be for a
> feature of the programming language itself.  The negotiation of new
> human vocabulary involves trying alternatives in the real world and
> seeing what sticks.

Can't we just look at this as what it is, instead of finding a huge,
trans-historical thing that tells us what it "should" be?  Let's just
let Matz decide.  Sorry to be so pedestrian :-)

> Based on Matz's most recent post, it sounds like that's what he's
> waiting for too.

I interpreted it differently; he said, as I read it, that he's
sticking with singleton class for now.  But as I've said, this is a
done deal: people are going to use a bunch of different terms, no
matter who says what at this point.


David

--
David A. Black
dblack@wobblini.net

"Ruby for Rails", forthcoming from Manning Publications, April 2006!
1fba4539b6cafe2e60a2916fa184fc2f?d=identicon&s=25 dblack (Guest)
on 2005-12-07 20:10
(Received via mailing list)
Hi --

On Wed, 7 Dec 2005, daz wrote:

>
> MenTaLguY wrote:
>
>> I don't know, man.  Personally at this point I think we should stand
>> back and let natural selection do its thing.
>
>
> But, IIUC, slaughter is frowned upon by civilised communities?

"[Ruby], red in tooth and claw" :-)


David

--
David A. Black
dblack@wobblini.net

"Ruby for Rails", forthcoming from Manning Publications, April 2006!
2cf6d8e639314abd751f83a72e9a2ac5?d=identicon&s=25 martindemello (Guest)
on 2005-12-07 21:16
(Received via mailing list)
dblack@wobblini.net wrote:
> On Wed, 7 Dec 2005, Martin DeMello wrote:
>
> Not quite:
>
>    ruby -ve 'class << 3; end'
>    ruby 1.9.0 (2005-05-20) [i686-linux]
>    -e:1: no singleton class for Fixnum (TypeError)

A very palpable hit :)

> already underway.
But IMO this is the only real way to make sure that, when we do
standardise on a term, it's a good one.

martin
1fba4539b6cafe2e60a2916fa184fc2f?d=identicon&s=25 dblack (Guest)
on 2005-12-07 21:32
(Received via mailing list)
Hi --

On Thu, 8 Dec 2005, Martin DeMello wrote:

>
>> already underway.
>
> But IMO this is the only real way to make sure that, when we do
> standardise on a term, it's a good one.

Or at least a frequently-used one :-)  I know it's possible to discuss
something to death, and it's possible that this has happened with
singleton-class renaming already.  But consider that someone just
coming across a reference to "Ruby's eigenclasses" (or whatever) isn't
even going to know that there's any history, discussion, uncertainty
-- basically, isn't going to know that there's any reason to think
about whether the term is or is not a good one.  They'll just accept
the term and start propagating it -- which, therefore, doesn't count
as a "vote", so to speak.

Also, the standard that's really emerging is the standard practice of
calling singleton classes by many different names.  Maybe we should
just embrace this.  It might lead to more publicity than choosing one
name :-)


David

--
David A. Black
dblack@wobblini.net

"Ruby for Rails", forthcoming from Manning Publications, April 2006!
47fb897113ebddae565f2f4b9f45ca1d?d=identicon&s=25 jonathan (Guest)
on 2005-12-08 02:58
transfire wrote:
>> 'Ad hoc' has too many negative connotations and singleton has a fairly
>> unambiguous meaning.
>
> I felt the same way at first, until I started using it, keeping in mind
> the strict definition --even the Latin definition: *for this*.
>

That's really interesting.  It's unfortunate that the most common use of
the term is a secondary meaning.  I guess using it will motivate people
to find out primary meaning.  I'm all for it. :)
47fb897113ebddae565f2f4b9f45ca1d?d=identicon&s=25 jonathan <zjll9@imail.etsu.edu> (Guest)
on 2005-12-08 03:21
jonathan wrote:
> transfire wrote:
>>> 'Ad hoc' has too many negative connotations and singleton has a fairly
>>> unambiguous meaning.
>>
>> I felt the same way at first, until I started using it, keeping in mind
>> the strict definition --even the Latin definition: *for this*.
>>
>
> That's really interesting.  It's unfortunate that the most common use of
> the term is a secondary meaning.  I guess using it will motivate people
> to find out primary meaning.  I'm all for it. :)

Just to clarify (I hadn't finished reading all the posts when I made the
above comment).  I don't mean to make my vote 'for' this term, but, I
meant that I was for using a term in a way that educates.  Most of us
are people that like to learn anyway. :)

Having many terms for the same thing isn't necessarily a bad thing.  It
happens in every other aspect of programming as well (class methods are
called 'member functions', 'methods', 'member methods', etc.).

How do you all think the term 'static class' fits?

Also, one more thing:

How do you actually implement the singleton pattern in Ruby?  Not being
able to return a self ptr from initialize seems to stump me.

--Jonathan
0ec4920185b657a03edf01fff96b4e9b?d=identicon&s=25 matz (Guest)
on 2005-12-08 03:32
(Received via mailing list)
Hi,

In message "Re: injecting dynamic methods into a class"
    on Thu, 8 Dec 2005 11:22:02 +0900, "jonathan <zjll9@imail.etsu.edu>"
<zjll9@imail.etsu.edu> writes:

|How do you all think the term 'static class' fits?

Nope, just because it's not static at all.

|How do you actually implement the singleton pattern in Ruby?  Not being
|able to return a self ptr from initialize seems to stump me.

Four ideas:

  * A plain object + singleton methods
  * A module with singleton methods
  * singleton library in the standard libraries
  * An ordinary class and pre-allocated object with convention not to
    create any other objects.

							matz.
E34b5cae57e0dd170114dba444e37852?d=identicon&s=25 logancapaldo (Guest)
on 2005-12-08 03:32
(Received via mailing list)
On Dec 7, 2005, at 9:22 PM, jonathan <zjll9@imail.etsu.edu> wrote:

>>
> are people that like to learn anyway. :)
>
> How do you actually implement the singleton pattern in Ruby?  Not
> being
> able to return a self ptr from initialize seems to stump me.
>
> --Jonathan
>
> --
> Posted via http://www.ruby-forum.com/.
>

Well the easy way is

require 'singleton'
class IWantToBeASingleton
      include Singleton
end

And the slighlty harder way

class IAlsoAmASingleton
        class << self
                private :new
         end
        def self.instance
               @inst ||= new
        end
end
45196398e9685000d195ec626d477f0e?d=identicon&s=25 transfire (Guest)
on 2005-12-08 03:40
(Received via mailing list)
> Just so you know since I've been so "anti-Trans" in the past I plan to
> look over Calibre and write about some of the gems (pun-intended) in
> there.

Cool thanks. I hope you find a "gem" of use to you.

T.
45196398e9685000d195ec626d477f0e?d=identicon&s=25 transfire (Guest)
on 2005-12-08 03:40
(Received via mailing list)
> Just so you know since I've been so "anti-Trans" in the past I plan to
> look over Calibre and write about some of the gems (pun-intended) in
> there.

Hey, thanks. That would be great! I hope you find some the "gems"
useful.

T.
47fb897113ebddae565f2f4b9f45ca1d?d=identicon&s=25 jonathan <zjll9@imail.etsu.edu> <zjll9@imail.etsu. (Guest)
on 2005-12-08 03:45
matz wrote:
> Hi,
>
> In message "Re: injecting dynamic methods into a class"
>     on Thu, 8 Dec 2005 11:22:02 +0900, "jonathan <zjll9@imail.etsu.edu>"
> <zjll9@imail.etsu.edu> writes:
>
> |How do you all think the term 'static class' fits?
>
> Nope, just because it's not static at all.
>

It seems to be a term that .NET (and I think C++) uses:

see <a
href="http://msdn2.microsoft.com/en-us/library/79b3xss3....

In what way would the class not be static in Ruby?  In the sense that
you can still metaprogram (or is it more than that)?

I think the term static refers to the fact that the data is static (that
is, there isn't a new copy of the data members for each instance) and
that each method is static (doesn't change any data members).  One could
argue that adding code to a class is dynamic, but it could be understood
that the term 'static' only refers to data.

I guess the term is not a *perfect* match.  But, then again, none of the
ones suggested, except maybe 'eigenclass' is.

--Jonathan
47fb897113ebddae565f2f4b9f45ca1d?d=identicon&s=25 jonathan <zjll9@imail.etsu.edu> <zjll9@imail.etsu. (Guest)
on 2005-12-08 03:47
jonathan <zjll9@imail.etsu.edu> <zjll9@imail.etsu. wrote:

> that each method is static (doesn't change any data members).  One could

Oops, meant to say 'doesn't change any non-static (or non-class-wide, or
instance-specific)' members.

--Jonathan
47fb897113ebddae565f2f4b9f45ca1d?d=identicon&s=25 jonathan (Guest)
on 2005-12-08 04:05
logancapaldo wrote:
> And the slighlty harder way
>
> class IAlsoAmASingleton
>         class << self
>                 private :new
>          end
>         def self.instance
>                @inst ||= new
>         end
> end

Ahh.  That makes sense.

Thanks!
0ec4920185b657a03edf01fff96b4e9b?d=identicon&s=25 matz (Guest)
on 2005-12-08 04:37
(Received via mailing list)
Hi,

In message "Re: injecting dynamic methods into a class"
    on Thu, 8 Dec 2005 11:45:18 +0900,
 "jonathan <zjll9@imail.etsu.edu> <zjll9@imail.etsu.edu>"
<zjll9@imail.etsu.edu> writes:

|> |How do you all think the term 'static class' fits?
|>
|> Nope, just because it's not static at all.

|It seems to be a term that .NET (and I think C++) uses:
|
|see <a
|href="http://msdn2.microsoft.com/en-us/library/79b3xss3....

I thought we were talking about so called singleton classes, right?
It's totally different from static classes in C# and C++.
Singleton classes in Ruby are:

  * created run time on demand
  * can be modified (or enhanced) run time
  * their methods may modify any instances
  * their scope are not limited to certain file

							matz.
E7559e558ececa67c40f452483b9ac8c?d=identicon&s=25 gwtmp01 (Guest)
on 2005-12-08 04:45
(Received via mailing list)
On Dec 7, 2005, at 9:22 PM, jonathan wrote:
> Having many terms for the same thing isn't necessarily a bad
> thing.  It
> happens in every other aspect of programming as well (class methods
> are
> called 'member functions', 'methods', 'member methods', etc.).

Yes but we don't have Class#member, Class#method, Class#member_method,
Class#attribute, and Class#feature, etc. in Ruby.  We have
Class#method and
that all by itself probably forces a canonical term for the concept.

I would guess that if there was no programatic way in Ruby to
reference or manipulate a singleton class then there wouldn't be such
a buzz about coming up with a standard name for it.

We have Object#class and Class#superclass which emphasize, if
not define, the canonical names for these things in Ruby.  There is no
similar standard method in Ruby that returns the object generated by
the expression:

	(class <<obj; self; end)

and since it is supremely awkward to type or say that expression to
refer to the concept, we all have our own habits in this regard and
only the social forces of the community to influence these habits.
I bet if you searched all the Ruby code ever written you would see
all sorts of things like:

	def vclass(obj)
	  (class <<obj; self; end)
         end

where vclass might be:  meta, singleton, sclass, virtclass, eclass,
eigen,
aclass, adhoc, shadow, and so on.  Everybody is coming up with their own
mnemonic for the concept because, well, you need a name if you are going
wrap up that expression in a method.

So all this is a long way of saying that what I really want for
Christmas
is a short name for (class <<obj; self; end).  But if I don't get that,
I'll still be very happy with getting Ruby 1.8.4, which I will brag
about
to all my friends who are still stuck with their crufty old static
language
tools.  :-)

Gary Wright
1fba4539b6cafe2e60a2916fa184fc2f?d=identicon&s=25 dblack (Guest)
on 2005-12-08 05:02
(Received via mailing list)
Hi --

On Thu, 8 Dec 2005, gwtmp01@mac.com wrote:

> So all this is a long way of saying that what I really want for Christmas
> is a short name for (class <<obj; self; end).  But if I don't get that,
> I'll still be very happy with getting Ruby 1.8.4, which I will brag about
> to all my friends who are still stuck with their crufty old static language
> tools.  :-)

I'm hoping my Kernel#singleton_class RCR will get approved in some
form once some of this is resolved.  It's partly a question of whether
the implementation of per-object behavior is going to continue to be
as class-based as it is now.


David

--
David A. Black
dblack@wobblini.net

"Ruby for Rails", forthcoming from Manning Publications, April 2006!
47fb897113ebddae565f2f4b9f45ca1d?d=identicon&s=25 jonathan <zjll9@imail.etsu.edu> (Guest)
on 2005-12-08 07:38
matz wrote:
> I thought we were talking about so called singleton classes, right?
> It's totally different from static classes in C# and C++.

Well, I thought we were talking about classes which contain only class
methods and class data (which are currently called 'singletons').  But,
in C# or C++ these are called 'static classes.'  I guess that makes
sense for them because the code itself can never change or be enhanced
(like it can be in Ruby).

> Singleton classes in Ruby are:
>
>   * created run time on demand
>   * can be modified (or enhanced) run time
>   * their methods may modify any instances
>   * their scope are not limited to certain file
>
> 							matz.

Ok.  That's what I meant by metaprogramming.  I wasn't aware of the
scope issue though.  Also, what do you mean by 'their methods may modify
any instances'?

But, yea, given the 'dynamic' nature of Ruby, it doesn't make sense to
say something is static.

--Jonathan
47fb897113ebddae565f2f4b9f45ca1d?d=identicon&s=25 jonathan <zjll9@imail.etsu.edu> <zjll9@imail.etsu. (Guest)
on 2005-12-08 07:46
gwtmp01 wrote:
> On Dec 7, 2005, at 9:22 PM, jonathan wrote:
>> Having many terms for the same thing isn't necessarily a bad
>> thing.  It
>> happens in every other aspect of programming as well (class methods
>> are
>> called 'member functions', 'methods', 'member methods', etc.).
>
> Yes but we don't have Class#member, Class#method, Class#member_method,
> Class#attribute, and Class#feature, etc. in Ruby.  We have
> Class#method and
> that all by itself probably forces a canonical term for the concept.
>

Ahh.  Ok.  I think I also gathered from other posts that it also helps
to be able to differentiate these for the purpose of error messages.
Well, this may be a solution:

Let the type of singleton which implements the singleton design pattern
remain as a 'singleton' in error messaging and introspection.  But, let
the class which is a singleton by having nothing but class methods be
known as a simpleton.

In essence, from the outside, they look the same (and please correct me
if I'm wrong because I don't know all the Ruby syntax yet, but in
essence I think they are the same).  Simpleton and singleton are
synonyms as far as I know.  And, these two ways of arriving at a
singleton produce the same effect for the consumer (but differentiating
them is nice for error messaging and introspection).

--Jonathan
0ec4920185b657a03edf01fff96b4e9b?d=identicon&s=25 matz (Guest)
on 2005-12-08 08:57
(Received via mailing list)
Hi,

In message "Re: injecting dynamic methods into a class"
    on Thu, 8 Dec 2005 15:39:06 +0900, "jonathan <zjll9@imail.etsu.edu>"
<zjll9@imail.etsu.edu> writes:

|> Singleton classes in Ruby are:
|>
|>   * created run time on demand
|>   * can be modified (or enhanced) run time
|>   * their methods may modify any instances
|>   * their scope are not limited to certain file
|>
|> 							matz.
|
|Ok.  That's what I meant by metaprogramming.  I wasn't aware of the
|scope issue though.  Also, what do you mean by 'their methods may modify
|any instances'?

Nevermind.  I was confusing const and static.  Silly.

							matz.
1fba4539b6cafe2e60a2916fa184fc2f?d=identicon&s=25 dblack (Guest)
on 2005-12-10 05:14
(Received via mailing list)
Hi --

On Thu, 8 Dec 2005, jonathan <zjll9@imail.etsu.edu>
<zjll9@imail.etsu.edu> wrote:

>> Class#method and
> known as a simpleton.
Do you know what the word "simpleton" means?  It's really not a
candidate for a name for a language construct.

Anyway -- I'm trying to follow along but not sure what you mean by
classes that have nothing but class methods and class data.  Can you
give a code example of such a class?


David

--
David A. Black
dblack@wobblini.net

"Ruby for Rails", forthcoming from Manning Publications, April 2006!
47fb897113ebddae565f2f4b9f45ca1d?d=identicon&s=25 jonathan <zjll9@imail.etsu.edu> <zjll9@imail.etsu. (Guest)
on 2005-12-10 07:28
dblack wrote:
> Anyway -- I'm trying to follow along but not sure what you mean by
> classes that have nothing but class methods and class data.  Can you
> give a code example of such a class?
>

Here's a very simple example (a global counter):

<code>

class SingletonCounter
  private_class_method :new
  attr_accessor :count
  @@counter = nil  # class var which pts to instance
  def initialize( count )
    @count = count
  end
  def SingletonCounter.create
    @@counter = new( 0 ) unless @@counter
    @@counter
  end
  def increment( inc_amt )
    @count += inc_amt
    return @count
  end
end

class Counter
  @@count = 0                      # class variable
  def Counter.increment( inc_amt ) # class method
    @@count = @@count + inc_amt
    return @@count
  end
end

sc = SingletonCounter.create
print sc.increment( 9 )
print sc.increment( 4 )

sc2 = SingletonCounter.create
print sc2.increment( 3 ) # points to same underlying obj as sc

c = Counter.new
print Counter.increment( 9 )  # in C#, you could do c.increment( 9 )
here
print Counter.increment( 4 )

c2 = Counter.new
print Counter.increment( 3 )

</code>

The first class is a true singleton and the second class is what is *in
essence* a singleton, but known as a static class in C#.  One thing that
C# will let you do that makes this more transparent is
instancevar.staticmethod().  That apparently isn't the case in Ruby, so
that makes them less equivalent.  (I suspected there would end up being
some syntax difference between the two, but the point I was making was
that they were the same in concept).

I don't know if any of this is really relevant, but hopefully you
understand statics, singletons, and C# a little better now. :)  BTW,
this discussion is continued in another thread called 'About class
methods'.

--J
Dce0999389d102f9a313af625375304c?d=identicon&s=25 dooby (Guest)
on 2005-12-10 11:36
(Received via mailing list)
dblack wrote:
> candidate for a name for a language construct.
>
> Anyway -- I'm trying to follow along but not sure what you mean by
> classes that have nothing but class methods and class data.  Can you
> give a code example of such a class?
>

Please Ignore.

http://qurl.net/oF

[**1]  http://www.usemod.com/cgi-bin/mb.pl?SockPuppet
1fba4539b6cafe2e60a2916fa184fc2f?d=identicon&s=25 dblack (Guest)
on 2005-12-10 15:22
(Received via mailing list)
Hi --

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

> class SingletonCounter
>  def increment( inc_amt )
>  end
> print Counter.increment( 9 )  # in C#, you could do c.increment( 9 )
> here
> print Counter.increment( 4 )
>
> c2 = Counter.new
> print Counter.increment( 3 )
>
> </code>
>
> The first class is a true singleton and the second class is what is *in
> essence* a singleton, but known as a static class in C#.

In Ruby it's just known as a class :-)  I'd highly recommend not
trying to shoehorn the term "static" into Ruby.  It's never going to
be a good fit.

(Don't neglect the Singleton module, by the way, which will do the
singleton-ing for you.)

There's nothing at the language level that stops you from adding an
instance method to Counter.  You can give a name to a style of coding
where you don't write instance methods, but it's definitely not a
language feature.


David

--
David A. Black
dblack@wobblini.net

"Ruby for Rails", forthcoming from Manning Publications, April 2006!
This topic is locked and can not be replied to.