Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > Ruby > Singleton Modules rather than Singleton Classes

Reply
Thread Tools

Singleton Modules rather than Singleton Classes

 
 
Trans
Guest
Posts: n/a
 
      09-01-2007
This recently came up in the thread entitled "Python-style
Decorators", so I thought it a fair idea to "formally" put it before
the Ruby community. Here's the deal...

Singleton classes already have more in common with modules than
classes by the very behaviors that distinguish a module from a class --
they cannot be instantiated and they can not be inherited. So why
exactly do we deem them classes at all? If instead we took them to be
actual modules, and used as such, it would open up some really nice
possibilities. For example:

class A
def self.x
"x"
end
end

class B
extend (class << A; self; end)
end

B.x #=> "x"

This makes it dead simple to pass along module class-level methods in
the class hierarchy. The immediate use of this change is apparent --no
more ClassMethods/included callback hacks required.

One thing to note about this example, the notation "(class << A; self;
end)" becomes a bit of a misnomer in light of the suggested change.
"A.singleton" or some other method name, would be far better.

Another possibility, which derives from the aforementioned thread, are
method decorators using singleton def notation:

class Example

def memoized.foo
...
end

end

It is not possible to meta-code this currently b/c the definition of
foo gets locked away in a singleton class where it can not be reused.
If that singleton could be included into a class (in this case
Example) then presto, problem solved, and a powerful new notation is
opened up to the Ruby programmer.

T.


 
Reply With Quote
 
 
 
 
Logan Capaldo
Guest
Posts: n/a
 
      09-01-2007
On 9/1/07, Trans <(E-Mail Removed)> wrote:
> This recently came up in the thread entitled "Python-style
> Decorators", so I thought it a fair idea to "formally" put it before
> the Ruby community. Here's the deal...
>
> Singleton classes already have more in common with modules than
> classes by the very behaviors that distinguish a module from a class --
> they cannot be instantiated and they can not be inherited. So why
> exactly do we deem them classes at all? If instead we took them to be
> actual modules, and used as such, it would open up some really nice
> possibilities. For example:
>


Counter proposal: remove singleton classes all together in favor of
simply having singleton methods. The useful facility of a singleton
class is that it allows you to have per-object methods (singleton
methods). Class and module are both misnomers for the "thing that acts
as a place to store singleton methods." By eliminating the visibility
of this implementation detail, it allows for other implementations to
be experimented with. The more you pin down how singleton methods are
implemented, and the more you start doing things with details of that
implementation the hard it becomes to have flexibility in that
implementation. This also removes the need to justify referring to
them as classes, and the false expectations this creates. My 2cents..
>
>


 
Reply With Quote
 
 
 
 
dblack@wobblini.net
Guest
Posts: n/a
 
      09-01-2007
Hi --

On Sun, 2 Sep 2007, Logan Capaldo wrote:

> On 9/1/07, Trans <(E-Mail Removed)> wrote:
>> This recently came up in the thread entitled "Python-style
>> Decorators", so I thought it a fair idea to "formally" put it before
>> the Ruby community. Here's the deal...
>>
>> Singleton classes already have more in common with modules than
>> classes by the very behaviors that distinguish a module from a class --
>> they cannot be instantiated and they can not be inherited. So why
>> exactly do we deem them classes at all? If instead we took them to be
>> actual modules, and used as such, it would open up some really nice
>> possibilities. For example:
>>

>
> Counter proposal: remove singleton classes all together in favor of
> simply having singleton methods. The useful facility of a singleton
> class is that it allows you to have per-object methods (singleton
> methods). Class and module are both misnomers for the "thing that acts
> as a place to store singleton methods." By eliminating the visibility
> of this implementation detail, it allows for other implementations to
> be experimented with. The more you pin down how singleton methods are
> implemented, and the more you start doing things with details of that
> implementation the hard it becomes to have flexibility in that
> implementation. This also removes the need to justify referring to
> them as classes, and the false expectations this creates. My 2cents..


But then you introduce a whole second model of how method lookup and
so forth works. What's nice about singleton classes is that they fit
into the same basic model as other classes; once the premise is
granted that every object can have a singleton class as well as a
"birth" class, it all flows from there. I like the fact that every
method lives in a class or module.

I would actually be happy for them to be singleton modules instead of
classes, though I don't really like the idea that one object can
extend itself with another object's singleton methods. Or, to put it
another way, I do like the possibility of strictly per-object
behavior, so I wouldn't want to see that done away with. Maybe if it
were done explicitly via dup'ing of some kind it would be OK.
Otherwise it's just multiple objects sharing a module, which is
basically what the non-singleton scenario already is.


David

--
* Books:
RAILS ROUTING (new! http://www.awprofessional.com/title/0321509242)
RUBY FOR RAILS (http://www.manning.com/black)
* Ruby/Rails training
& consulting: Ruby Power and Light, LLC (http://www.rubypal.com)

 
Reply With Quote
 
Robert Dober
Guest
Posts: n/a
 
      09-01-2007
On 9/1/07, http://www.velocityreviews.com/forums/(E-Mail Removed) <(E-Mail Removed)> wrote:
> Hi --
>
> On Sun, 2 Sep 2007, Logan Capaldo wrote:
>
> > On 9/1/07, Trans <(E-Mail Removed)> wrote:
> >> This recently came up in the thread entitled "Python-style
> >> Decorators", so I thought it a fair idea to "formally" put it before
> >> the Ruby community. Here's the deal...
> >>
> >> Singleton classes already have more in common with modules than
> >> classes by the very behaviors that distinguish a module from a class --
> >> they cannot be instantiated and they can not be inherited. So why
> >> exactly do we deem them classes at all? If instead we took them to be
> >> actual modules, and used as such, it would open up some really nice
> >> possibilities. For example:
> >>

> >
> > Counter proposal: remove singleton classes all together in favor of
> > simply having singleton methods. The useful facility of a singleton
> > class is that it allows you to have per-object methods (singleton
> > methods). Class and module are both misnomers for the "thing that acts
> > as a place to store singleton methods." By eliminating the visibility
> > of this implementation detail, it allows for other implementations to
> > be experimented with. The more you pin down how singleton methods are
> > implemented, and the more you start doing things with details of that
> > implementation the hard it becomes to have flexibility in that
> > implementation. This also removes the need to justify referring to
> > them as classes, and the false expectations this creates. My 2cents..

>
> But then you introduce a whole second model of how method lookup and
> so forth works. What's nice about singleton classes is that they fit
> into the same basic model as other classes; once the premise is
> granted that every object can have a singleton class as well as a
> "birth" class, it all flows from there. I like the fact that every
> method lives in a class or module.
>
> I would actually be happy for them to be singleton modules instead of
> classes, though I don't really like the idea that one object can
> extend itself with another object's singleton methods. Or, to put it
> another way, I do like the possibility of strictly per-object
> behavior, so I wouldn't want to see that done away with. Maybe if it
> were done explicitly via dup'ing of some kind it would be OK.
> Otherwise it's just multiple objects sharing a module, which is
> basically what the non-singleton scenario already is.
>
>
> David
>
> --
> * Books:
> RAILS ROUTING (new! http://www.awprofessional.com/title/0321509242)
> RUBY FOR RAILS (http://www.manning.com/black)
> * Ruby/Rails training
> & consulting: Ruby Power and Light, LLC (http://www.rubypal.com)
>

All three proposals make sense to me, what does not make sense to me
is the current state of affairs, as long as
instance_eval{
def a; @a end
}
works on arbitrary objects I will stay confused .
It probably all depends on what kind of OO Style one prefers,
Personally I would be looking forward to some serious simplifications, like e.g.
* Any unbound method can be bound to any object.
* Methods and Blocks could be unified.
* Method definitions in classes behave as in Modules.
* define_method defines a method on any object
* define_instance_method defines an instance method on any object.
* Any object can have instances. (well and classes just went away)

Well just some ideas more

Robert
>



--
I'm an atheist and that's it. I believe there's nothing we can know
except that we should be kind to each other and do what we can for
other people.
-- Katharine Hepburn

 
Reply With Quote
 
ara.t.howard
Guest
Posts: n/a
 
      09-10-2007

On Sep 1, 2007, at 2:14 PM, Logan Capaldo wrote:

>
> Counter proposal: remove singleton classes all together in favor of
> simply having singleton methods. The useful facility of a singleton
> class is that it allows you to have per-object methods (singleton
> methods). Class and module are both misnomers for the "thing that acts
> as a place to store singleton methods." By eliminating the visibility
> of this implementation detail, it allows for other implementations to
> be experimented with. The more you pin down how singleton methods are
> implemented, and the more you start doing things with details of that
> implementation the hard it becomes to have flexibility in that
> implementation. This also removes the need to justify referring to
> them as classes, and the false expectations this creates. My 2cents..


i think i've done as much meta-programming as anyone out there and i
would not like to see that chance. the reason is that the
singleton_class is also a nice place to store *state* - not only
methods - when doing deep ruby magic. otherwise the whole affair of
transforming singleton classes into modules seems reasonable but
superfluous to me: it's just so easy to do

module M; def x() 'x' end; end

class A; extend M; end

class B; extend M; end

B.x #=> 'x'

that is hardly seems worth all the c coding and inevitable bugs even
though the idea seems sounds. maybe 2.0?

2cts.


a @ http://drawohara.com/
--
we can deny everything, except that we have the possibility of being
better. simply reflect on that.
h.h. the 14th dalai lama




 
Reply With Quote
 
Logan Capaldo
Guest
Posts: n/a
 
      09-10-2007
On 9/10/07, ara.t.howard <(E-Mail Removed)> wrote:
> > i think i've done as much meta-programming as anyone out there and i

> would not like to see that chance. the reason is that the
> singleton_class is also a nice place to store *state* - not only
> methods - when doing deep ruby magic.


Care to give an example?

 
Reply With Quote
 
ara.t.howard
Guest
Posts: n/a
 
      09-11-2007

On Sep 10, 2007, at 4:32 PM, Logan Capaldo wrote:

> Care to give an example?


sure.

file: traits.rb
...
8 class Object
9 #--{{{
10 def singleton_method_added(*a, &b)
11 #--{{{
12 ret = super rescue nil
13 obj = self
14 obj.__trait_singleton_class.__trait_module_eval
{ @__trait_singleton_super = obj }
15 ret
16 #--}}}
17 end
...

this object is used in the search path: traits implements attr like
methods with inheritance.


a @ http://drawohara.com/
--
we can deny everything, except that we have the possibility of being
better. simply reflect on that.
h.h. the 14th dalai lama




 
Reply With Quote
 
Robert Klemme
Guest
Posts: n/a
 
      09-11-2007
2007/9/1, Trans <(E-Mail Removed)>:
> This recently came up in the thread entitled "Python-style
> Decorators", so I thought it a fair idea to "formally" put it before
> the Ruby community. Here's the deal...
>
> Singleton classes already have more in common with modules than
> classes by the very behaviors that distinguish a module from a class --
> they cannot be instantiated and they can not be inherited. So why
> exactly do we deem them classes at all? If instead we took them to be
> actual modules, and used as such, it would open up some really nice
> possibilities. For example:
>
> class A
> def self.x
> "x"
> end
> end
>
> class B
> extend (class << A; self; end)
> end
>
> B.x #=> "x"
>
> This makes it dead simple to pass along module class-level methods in
> the class hierarchy. The immediate use of this change is apparent --no
> more ClassMethods/included callback hacks required.


You do not need that, because the functionality is there already:

$ ruby <<XXX
> class A
> def self.x
> "x"
> end
> end
> class B < A; end
> p B.x
> XXX

"x"

> One thing to note about this example, the notation "(class << A; self;
> end)" becomes a bit of a misnomer in light of the suggested change.
> "A.singleton" or some other method name, would be far better.
>
> Another possibility, which derives from the aforementioned thread, are
> method decorators using singleton def notation:
>
> class Example
>
> def memoized.foo
> ...
> end
>
> end
>
> It is not possible to meta-code this currently b/c the definition of
> foo gets locked away in a singleton class where it can not be reused.
> If that singleton could be included into a class (in this case
> Example) then presto, problem solved, and a powerful new notation is
> opened up to the Ruby programmer.


I'd generally prefer to define modules explicitly and extend classes
with them as Ara suggested. IMHO that's a cleaner way to achieve what
you want and it also documents things more nicely (especially you can
look at inheritance etc.). My 0.02EUR

Kind regards

robert

 
Reply With Quote
 
Logan Capaldo
Guest
Posts: n/a
 
      09-11-2007
On 9/10/07, ara.t.howard <(E-Mail Removed)> wrote:
>
> On Sep 10, 2007, at 4:32 PM, Logan Capaldo wrote:
>
> > Care to give an example?

>
> sure.
>
> file: traits.rb
> ...
> 8 class Object
> 9 #--{{{
> 10 def singleton_method_added(*a, &b)
> 11 #--{{{
> 12 ret = super rescue nil
> 13 obj = self
> 14 obj.__trait_singleton_class.__trait_module_eval
> { @__trait_singleton_super = obj }
> 15 ret
> 16 #--}}}
> 17 end
> ...


I assume __trait_singleton_class is (class << obj; self; end) and
__trait_module_module is a wrapper around module_eval?

You can do this without ivars, just define a __trait_singleton_super
singleton method that returns obj, Or you can do it with ivars but
keep the ivar in the object instead of the singleton class.

>
> this object is used in the search path: traits implements attr like
> methods with inheritance.
>
>
> a @ http://drawohara.com/
> --
> we can deny everything, except that we have the possibility of being
> better. simply reflect on that.
> h.h. the 14th dalai lama
>
>
>
>
>


 
Reply With Quote
 
Trans
Guest
Posts: n/a
 
      09-12-2007


On Sep 11, 1:55 am, "Robert Klemme" <(E-Mail Removed)>
wrote:

> I'd generally prefer to define modules explicitly and extend classes
> with them as Ara suggested. IMHO that's a cleaner way to achieve what
> you want and it also documents things more nicely (especially you can
> look at inheritance etc.). My 0.02EUR


That is simply not correct. Fist of all, you do not control all code,
so you can not make someone else modularized their module's class-
level methods, so you can later augment them with meta-code. Secondly,
the primary point has nothing to do with the fact that one can manage
workarounds, of course there are ways, but b/c of limitations they are
fragile and inefficient. Lastly, you are missing the point when you
you say, "prefer to define modules explicitly... that's a cleaner way
to achieve what you want". That's not the issue. Again, I encourage
you to have a look as Facets' inheritor.rb lib to get a better
understanding of this.

T.


 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Singleton classes and Singleton pattern Wilhelm Ruby 1 10-11-2006 01:08 PM
Re: Private LAN: why should the gateway address be at the low end of the range, rather than at the high end. Ted Jones Cisco 11 11-04-2005 05:56 AM
Main Advantages i get when i do a stand alone app in .Net rather than in VB. Punya Narra ASP .Net 5 02-17-2004 12:02 PM
Using Src Rather Than CodeBehind in Web User Controls Nehal Shah ASP .Net 6 11-14-2003 01:31 AM



Advertisments