Hello, I was under the impresssion that Ruby 1.9 will provide Object#singleton_class (or #eigen_class or #meta_class), which would save us the trouble of writing "class << self; self; end" everywhere. But in Ruby 1.9.1-rc2, I do not see this: >> RUBY_DESCRIPTION => "ruby 1.9.1p0 (2009-01-20 revision 21700) [i686-linux]" >> Object.instance_methods.grep(/class|singleton|eigen|meta/) => [:class, :singleton_methods, :define_singleton_method] Was Object#singleton_class (or #eigen_class or #meta_class) planned for Ruby 1.9 or 2.0? Thanks for your consideration.
on 30.01.2009 09:24
on 30.01.2009 12:18
Hi -- On Fri, 30 Jan 2009, Suraj Kurapati wrote: > >>> Object.instance_methods.grep(/class|singleton|eigen|meta/) > => [:class, :singleton_methods, :define_singleton_method] > > Was Object#singleton_class (or #eigen_class or #meta_class) planned for > Ruby 1.9 or 2.0? Not that I remember hearing about. I'd certainly like to see it. David -- David A. Black / Ruby Power and Light, LLC Ruby/Rails consulting & training: http://www.rubypal.com Coming in 2009: The Well-Grounded Rubyist (http://manning.com/black2) http://www.wishsight.com => Independent, social wishlist management!
on 30.01.2009 16:32
Hi,
In message "Re: Object#singleton_class in Ruby 1.9?"
on Fri, 30 Jan 2009 20:15:17 +0900, "David A. Black"
<dblack@rubypal.com> writes:
|> Was Object#singleton_class (or #eigen_class or #meta_class) planned for
|> Ruby 1.9 or 2.0?
|
|Not that I remember hearing about. I'd certainly like to see it.
We still don't have consensus on the name. eigenclass?
In that case, should we rename singleton_method to eigenmethod?
matz.
on 30.01.2009 16:51
On Fri, Jan 30, 2009 at 10:28 AM, Yukihiro Matsumoto <matz@ruby-lang.org> wrote: > We still don't have consensus on the name. eigenclass? > In that case, should we rename singleton_method to eigenmethod? I wonder if this controversy has died down. There are people with their favorites, sure, but does anyone really oppose singleton_class? -greg
on 30.01.2009 16:56
On Jan 30, 2009, at 9:47 AM, Gregory Brown wrote: >> |> Ruby 1.9 or 2.0? >> | >> |Not that I remember hearing about. I'd certainly like to see it. >> >> We still don't have consensus on the name. eigenclass? >> In that case, should we rename singleton_method to eigenmethod? > > I wonder if this controversy has died down. There are people with > their favorites, sure, but does anyone really oppose singleton_class? I'm for singleton_class. It's what the official documentation has used for a long time now. It's also not like it will be the only overloaded term in computing. James Edward Gray II
on 30.01.2009 17:50
On Jan 30, 2009, at 10:53 AM, James Gray wrote: > I'm for singleton_class. It's what the official documentation has > used for a long time now. It's also not like it will be the only > overloaded term in computing. eigenton_class? :-) eigen_class or singleton_class doesn't really matter to me at this point but I do feel strongly that the object returned by: (class <<obj; self; end) should be available via a simple method call rather than only via that expression. Gary Wright
on 30.01.2009 18:46
Yukihiro Matsumoto wrote: > Hi, > > In message "Re: Object#singleton_class in Ruby 1.9?" > on Fri, 30 Jan 2009 20:15:17 +0900, "David A. Black" > <dblack@rubypal.com> writes: > > |> Was Object#singleton_class (or #eigen_class or #meta_class) planned for > |> Ruby 1.9 or 2.0? > | > |Not that I remember hearing about. I'd certainly like to see it. > > We still don't have consensus on the name. eigenclass? > In that case, should we rename singleton_method to eigenmethod? Since you make mention of "eigenclass", that would seem to be your bent. And I say, go for it! "eigenmethod"? Fantastic! Do it, do it, do it! It may be Germanic, but I for one like the shorter method names anyway. And certainly _Why has done enough for Ruby to deserve a little of his charm to shine through the language... it will just give Ruby another unique touch that her fans can revel in. Not to mention, no more Singleton vs. singleton controversy. Big smiles and all thumbs up, T.
on 30.01.2009 18:53
Yukihiro Matsumoto wrote: > Hi, > > In message "Re: Object#singleton_class in Ruby 1.9?" > on Fri, 30 Jan 2009 20:15:17 +0900, "David A. Black" > <dblack@rubypal.com> writes: > > |> Was Object#singleton_class (or #eigen_class or #meta_class) planned for > |> Ruby 1.9 or 2.0? > | > |Not that I remember hearing about. I'd certainly like to see it. > > We still don't have consensus on the name. eigenclass? Sorry, I only mentioned the other names because they were all proposed when we first discussed this (back in 2006, I think). Ruby was the first language where I learned the concept of "singleton class" (not the design pattern) so I think it makes sense to keep that name. > In that case, should we rename singleton_method to eigenmethod? Is this not a larger (disruptive) change than simply adding a new Object#singleton_class method? Thanks for your consideration.
on 30.01.2009 18:53
Hi -- On Sat, 31 Jan 2009, Yukihiro Matsumoto wrote: > We still don't have consensus on the name. eigenclass? > In that case, should we rename singleton_method to eigenmethod? No, *please* don't. It would mean having to re-edit books as well as code.... There's been enough change recently :-) David -- David A. Black / Ruby Power and Light, LLC Ruby/Rails consulting & training: http://www.rubypal.com Coming in 2009: The Well-Grounded Rubyist (http://manning.com/black2) http://www.wishsight.com => Independent, social wishlist management!
on 30.01.2009 18:59
Thomas Sawyer wrote: > Yukihiro Matsumoto wrote: >> We still don't have consensus on the name. eigenclass? >> In that case, should we rename singleton_method to eigenmethod? > > Since you make mention of "eigenclass", that would seem to be your bent. > And I say, go for it! "eigenmethod"? Fantastic! Do it, do it, do it! In that case, could we make the names more readable by adding an underscore after "eigen"? I find it more difficult to parse the names otherwise. Object#eigen_class Object#eigen_methods Object#define_eigen_method > Not to mention, no more Singleton vs. singleton controversy. This is indeed a good benefit. Thanks for your consideration.
on 30.01.2009 20:18
Suraj Kurapati wrote: > Thomas Sawyer wrote: >> Yukihiro Matsumoto wrote: >>> We still don't have consensus on the name. eigenclass? >>> In that case, should we rename singleton_method to eigenmethod? >> >> Since you make mention of "eigenclass", that would seem to be your bent. >> And I say, go for it! "eigenmethod"? Fantastic! Do it, do it, do it! > > In that case, could we make the names more readable by adding an > underscore after "eigen"? I find it more difficult to parse the names > otherwise. > > Object#eigen_class > Object#eigen_methods > Object#define_eigen_method Interesting, I find the other more readable, 'class' is like a suffix to me, along the lines of 'name' in methods like #basename and #dirname. Just personal preference of course. I'm don't think there is any true rational for one over the other. T.
on 30.01.2009 20:20
David A. Black wrote: > Hi -- > > On Sat, 31 Jan 2009, Yukihiro Matsumoto wrote: > >> We still don't have consensus on the name. eigenclass? >> In that case, should we rename singleton_method to eigenmethod? > > No, *please* don't. It would mean having to re-edit books as well as > code.... There's been enough change recently :-) David! How else are you supposed to sell 2nd and 3rd editions! ;) T.
on 30.01.2009 21:00
Thomas Sawyer wrote: > Suraj Kurapati wrote: >> In that case, could we make the names more readable by adding an >> underscore after "eigen"? I find it more difficult to parse the names >> otherwise. >> >> Object#eigen_class >> Object#eigen_methods >> Object#define_eigen_method > > Interesting, I find the other more readable, 'class' is like a suffix to > me, along the lines of 'name' in methods like #basename and #dirname. The problem I have with words like "basename" is that, to me, they are not actually words. For example, I pronounce "basename" as two separate words "base, name" (with a brief pause in between) not as a continuous word "basen-a-me" (without any pause in between). The same applies to "dirname", which I pronounce as "dir, name". In contrast, "singleton" is actually pronounced continuously as "sin-gel-ton", not as "single, ton", so I have no need to insert underscores in that word. In short, how a word is pronounced tells me when to insert underscores. > Just personal preference of course. I'm don't think there is any true > rational for one over the other. I beg to differ and I think there is a rationale (see above). Thanks for your consideration.
on 30.01.2009 21:59
On Fri, Jan 30, 2009 at 4:47 PM, Gregory Brown <gregory.t.brown@gmail.com> wrote: > I wonder if this controversy has died down. There are people with > their favorites, sure, but does anyone really oppose singleton_class? singleton_class is definitely the best (specially when we consider that word 'signleton' already appeared in ruby). What I don't like in "eigenclass" is that it's not english word (AFAIR it's from germany 'egein' word). -- Pozdrawiam Rados³aw Bu³at http://radarek.jogger.pl - mój blog
on 30.01.2009 22:54
Suraj Kurapati wrote: >> Just personal preference of course. I'm don't think there is any true >> rationale for one over the other. > > I beg to differ and I think there is a rationale (see above). Never_the_less this is English, a close relative of German, and it these languages conjoined words are common_place. T.
on 30.01.2009 23:24
Thomas Sawyer wrote: > Suraj Kurapati wrote: > >>> Just personal preference of course. I'm don't think there is any true >>> rationale for one over the other. >> >> I beg to differ and I think there is a rationale (see above). > > Never_the_less this is English, a close relative of German, and in these > languages conjoined words are common_place. Good point and excellent illustration! Until seeing your example, I never realized how well underscores flow with text, in comparison to hyphens: nevertheless vs. never-the-less vs. never_the_less vs. neverTheLess commonplace vs. common-place vs. common_place vs. commonPlace Of all the typographic conventions listed in the above example, I heavily prefer snake_case, which is thankfully prevalent in Ruby. This is one aspect of Ruby that I found very attractive, compared to, say, Python, where the firstconventionintheaboveexample is prevalent. (A personal preference, I agree.) Generally speaking, it's surprising that a better typographic convention would arise from computer science rather than from literature. Perhaps we may someday find that, in the increasingly digital future, people would begin using under_scores as an alternative to the traditional process of compound words being initially hyphenated (e.g. under-score) and later not hyphenated (e.g. underscore). Cheers.
on 31.01.2009 00:01
On Fri, Jan 30, 2009 at 5:46 PM, Gary Wright <gwtmp01@mac.com> wrote: > eigen_class or singleton_class doesn't really matter to > me at this point but I do feel strongly that the object > returned by: > > (class <<obj; self; end) > > should be available via a simple method call rather > than only via that expression. I completely agree with this point of view. I don't mind which name gets chosen, but please, choose one :-). Jesus.
on 31.01.2009 06:00
Jesús Gabriel y Galán wrote: > On Fri, Jan 30, 2009 at 5:46 PM, Gary Wright <gwtmp01@mac.com> wrote: >> eigen_class or singleton_class doesn't really matter to >> me at this point but I do feel strongly that the object >> returned by: >> >> (class <<obj; self; end) >> >> should be available via a simple method call rather >> than only via that expression. > > I completely agree with this point of view. I don't mind which name > gets chosen, but please, choose one :-). > > Jesus. I thought you were making an exclamation, until I realized that was actually your name. :) Hope that doesn't offend --with a name like mine I know how it can be. It just gave me a good laugh, so I thought I'd share it. T.
on 31.01.2009 11:29
On Sat, Jan 31, 2009 at 6:06 AM, Thomas Sawyer <transfire@gmail.com> wrote: > Jesús Gabriel y Galán wrote: > I thought you were making an exclamation, until I realized that was > actually your name. :) > > Hope that doesn't offend --with a name like mine I know how it can be. > It just gave me a good laugh, so I thought I'd share it. No problem. In Spain my name is used as an exclamation when someone sneezes, so I'm pretty much used to these kind of things. In any case, I also find it funny sometimes... Jesus ! PS: I might start changing the dot for an exclamation mark in my signature :-)
on 31.01.2009 14:13
On Fri, Jan 30, 2009 at 3:28 PM, Yukihiro Matsumoto <matz@ruby-lang.org> wrote: > We still don't have consensus on the name. eigenclass? > In that case, should we rename singleton_method to eigenmethod? > > matz. Personally, I prefer singleton_class. But I would rather it had an official name than my preference held anything up. I suspect there is a strong consensus that it should be named, whatever the name. I doubt we'll ever get consensus on ~what~ that name should be. :) Regards, Sean
on 31.01.2009 18:18
On Sat, Jan 31, 2009 at 8:12 AM, Sean O'Halpin <sean.ohalpin@gmail.com> wrote: >> > name should be. :) Definitely. I was implying that I don't think *too* many people hate singleton_class, but don't get me wrong, even if matz added Object#matz_is_awesome and had it do this operation, I'd be happy. :) -greg
on 31.01.2009 19:18
On Fri, Jan 30, 2009 at 4:28 PM, Yukihiro Matsumoto <matz@ruby-lang.org> wrote: > We still don't have consensus on the name. eigenclass? > In that case, should we rename singleton_method to eigenmethod? > > matz. Actually I am totally against it, in core that is. It would be nice to have a standard library extension for this, e.g. meta-ruby. I was really impressed about by David's keynote at Rubyconf. Just thought to share this thoughts in case I am not a minority. Cheers Robert
on 31.01.2009 21:03
Robert Dober wrote: > On Fri, Jan 30, 2009 at 4:28 PM, Yukihiro Matsumoto <matz@ruby-lang.org> > wrote: >> We still don't have consensus on the name. eigenclass? >> In that case, should we rename singleton_method to eigenmethod? >> >> matz. > > Actually I am totally against it, in core that is. It would be nice to > have a standard library extension for this, e.g. meta-ruby. > I was really impressed about by David's keynote at Rubyconf. Just > thought to share this thoughts in case I am not a minority. You are against having a method altogether, you mean? I take it because of the very nature singleton_methods / eigenmethods. And, I'm guessing, you prescribe to the idea that the only good way to the singleton "space" is to include modules into it, rather than defining methods directly. There was a blog post around somewhere to that effect. It was a good article. I wish I could dig it up now, but I'm not finding it. Perhaps someone else has the link? In any case, if that's what you mean, then I generally agree. That article was right, there rarely is a good reason to define methods directly into the singleton, one should be including a module with the methods defined in it instead. The only exception may be class-level methods, but even then using #extend deserves more merit. Taking that idea to heart perhaps a reorientation on the matter is warranted. Consider this form in place of the usual 'class << self': class X extend Module.new { ... } end Not quite as elegant since we can't use do...end. But if #extend could take a block: class X extend do ... end end Then the issue becomes transparent. Even for regular objects: obj.extend do ... end This is not to say that a singleton_class/eigenclass method would never be of use, but it would certainly mitigate the need for it a great deal. (One might also take away from this that a better name for it, if it were given a method name, would be #extension, but I mention that only as an aside.) T.
on 31.01.2009 21:16
On Sun, 1 Feb 2009, Robert Dober wrote: >> >> We still don't have consensus on the name. eigenclass? >> In that case, should we rename singleton_method to eigenmethod? >> >> matz. > > Actually I am totally against it, in core that is. It would be nice to > have a standard library extension for this, e.g. meta-ruby. > I was really impressed about by David's keynote at Rubyconf. Just > thought to share this thoughts in case I am not a minority. I'd like to have a singleton_class method, but even if there isn't one, I would definitely not like a meta-ruby standard extension. It suggests much too clear a separation between programming and metaprogramming in Ruby, whereas part of the coolness of the language is how interoperative it all is (e.g., the very fact that singleton methods are stored in classes, which in turn fit into the whole class/object model in a predictable way). David -- David A. Black / Ruby Power and Light, LLC Ruby/Rails consulting & training: http://www.rubypal.com Coming in 2009: The Well-Grounded Rubyist (http://manning.com/black2) http://www.wishsight.com => Independent, social wishlist management!
on 31.01.2009 21:39
On Jan 31, 2009, at 11:18 AM, Gregory Brown wrote: >>> |> Was Object#singleton_class (or #eigen_class or #meta_class) >> Personally, I prefer singleton_class. But I would rather it had an >> official name than my preference held anything up. >> >> I suspect there is a strong consensus that it should be named, >> whatever the name. I doubt we'll ever get consensus on ~what~ that >> name should be. :) > > Definitely. I was implying that I don't think *too* many people hate > singleton_class, but don't get me wrong, even if matz added > Object#matz_is_awesome and had it do this operation, I'd be happy. :) I've changing my vote. I now want: matz_class() No one can beat that. :) James Edward Gray II
on 31.01.2009 22:02
James Gray wrote: > Gregory Brown wrote: >> Matz wrote: >>> We still don't have consensus on the name. eigenclass? >>> In that case, should we rename singleton_method to eigenmethod? >> >> I wonder if this controversy has died down. There are people with >> their favorites, sure, but does anyone really oppose singleton_class? > > I'm for singleton_class. It's what the official documentation has > used for a long time now. It's also not like it will be the only > overloaded term in computing. I filed a request for Object#singleton_class in the Ruby Issue Tracking System: http://redmine.ruby-lang.org/issues/show/1082 Thanks for your consideration.
on 31.01.2009 22:24
Hi -- On Sun, 1 Feb 2009, Suraj Kurapati wrote: >> used for a long time now. It's also not like it will be the only >> overloaded term in computing. > > I filed a request for Object#singleton_class in the Ruby Issue Tracking > System: > > http://redmine.ruby-lang.org/issues/show/1082 Good ol' RCR 231, or whatever it was :-) David -- David A. Black / Ruby Power and Light, LLC Ruby/Rails consulting & training: http://www.rubypal.com Coming in 2009: The Well-Grounded Rubyist (http://manning.com/black2) http://www.wishsight.com => Independent, social wishlist management!
on 31.01.2009 23:03
On Sat, Jan 31, 2009 at 9:13 PM, David A. Black <dblack@rubypal.com> wrote: <snip> > I'd like to have a singleton_class method, but even if there isn't > one, I would definitely not like a meta-ruby standard extension. It > suggests much too clear a separation between programming and > metaprogramming in Ruby, whereas part of the coolness of the language > is how interoperative it all is (e.g., the very fact that singleton > methods are stored in classes, which in turn fit into the whole > class/object model in a predictable way). Well please let me rephrase this: I think #singleton_class is a great name. I want it, but rather than in core in a standard library, or even a core class. However that consideration was OT - 4 which I apologize - and it might indeed be worth a discussion for 2.0 if 'nuff people think like that. Back OnT, I really think it is too late to change #singleton_class it has become so much used in Ruby's jargon. I am well aware of the ambiguity with the Singleton pattern, but I feel it is enough related to still be the ideal choice. R.
on 01.02.2009 09:03
On Sat, Jan 31, 2009 at 8:03 PM, Thomas Sawyer <transfire@gmail.com> wrote: [snip] > > end > I like this - how do you see it working alongside the proposed #class_extension from a while ago? I guess #extend would work as above (i.e. defines singleton methods on instances), where #class_extension (or #class_extend?) methods/modules would both extend a class and be inherited by subclasses. I forget where the discussions on module inheritance ended up. Would you have a #module_extend method too or would #class_extension work for both classes and modules (in which case it should be renamed or alased)? > This is not to say that a singleton_class/eigenclass method would never > be of use, but it would certainly mitigate the need for it a great deal. > (One might also take away from this that a better name for it, if it > were given a method name, would be #extension, but I mention that only > as an aside.) I think you're onto something here - conceptually, #extend, singleton methods and the-class-that-cannot-be-named are closely related but you wouldn't know that from their names (or lack of them). Perhaps #extension_class? Regards, Sean
on 01.02.2009 13:04
Hi -- On Sun, 1 Feb 2009, Sean O'Halpin wrote: >> Not quite as elegant since we can't use do...end. But if #extend could >> obj.extend do >> ... >> end >> > > I like this - how do you see it working alongside the proposed > #class_extension from a while ago? > > I guess #extend would work as above (i.e. defines singleton methods on > instances), where #class_extension (or #class_extend?) methods/modules > would both extend a class and be inherited by subclasses. I forget I wouldn't want to see 'extend' start to mean both adding a module to the lookup path, and adding methods to the singleton class, depending on the context. I guess obj.extend do ... could create an anonymous module, though I've never had an issue with just creating it with Module.new or using a named module. > I think you're onto something here - conceptually, #extend, singleton > methods and the-class-that-cannot-be-named are closely related but you > wouldn't know that from their names (or lack of them). They're related conceptually but they also fit into the object model nicely: every method is defined in a class or module; every object has a lookup path of classes and modules. I know Matz has said that the main thrust of per-object behavior is per-object behavior, and that the way it's implemented (singleton class, which, like other classes, can include modules) is secondary, but there's a tremendous advantage to having it blend into the overall landscape, I think. I've seen literally hundreds of "Ah ha!" moments where people suddenly grasp the whole per-object thing because once you get the idea of every object having a singleton class, you don't have to learn anything else new (with regard to #extend, etc.). David -- David A. Black / Ruby Power and Light, LLC Ruby/Rails consulting & training: http://www.rubypal.com Coming in 2009: The Well-Grounded Rubyist (http://manning.com/black2) http://www.wishsight.com => Independent, social wishlist management!
on 01.02.2009 13:41
On Sun, Feb 1, 2009 at 9:02 AM, Sean O'Halpin <sean.ohalpin@gmail.com> wrote: >> Not quite as elegant since we can't use do...end. But if #extend could We surely can! >> take a block: >> >> class X >> extend do >> ... >> end >> end >> >> Then the issue becomes transparent. Even for regular objects: >> module Kernel alias_method :__extend__, :extend def extend mod=nil, &blk __extend__( mod || Module::new( &blk ) ) self end end class A extend do def a;42 end end end a = Object::new.extend do def b; 49 end end I believe that these things are better done to your own taste and shell not make the core larger as it is already, because there simply is no account for taste. HTH Robert
on 01.02.2009 15:54
On Sun, Feb 1, 2009 at 12:03 PM, David A. Black <dblack@rubypal.com> wrote: > > They're related conceptually but they also fit into the object model > nicely: every method is defined in a class or module; every object has > a lookup path of classes and modules. I know Matz has said that the > main thrust of per-object behavior is per-object behavior, and that > the way it's implemented (singleton class, which, like other classes, > can include modules) is secondary, but there's a tremendous advantage > to having it blend into the overall landscape I agree. After all, subclasses lookup class methods in a parent class's singleton class and clones inherit from an instance's, e.g. class A def self.foo "foo" end end class B < A end a = A.new def a.foo "bar" end b = a.clone puts B.foo puts b.foo # >> foo # >> bar That is hardly secondary behaviour. We can access an instance's class by name (via object.class) - why not the singleton (or extension) class? > I think. I've seen > literally hundreds of "Ah ha!" moments where people suddenly grasp the > whole per-object thing because once you get the idea of every object > having a singleton class, you don't have to learn anything else new > (with regard to #extend, etc.). Well, not hundreds in my case, but it's definitely one of those epiphany moments (along with 'classes are objects too'). I think naming the elements involved similarly (extend, extension_class, extension_methods, etc.) would help clarify the relationship between these concepts. (As an aside - why is there no method #extended_modules analogous to #included_modules?) Regards, Sean
on 01.02.2009 20:43
Hi -- On Sun, 1 Feb 2009, Sean O'Halpin wrote: > I agree. After all, subclasses lookup class methods in a parent > def a.foo > by name (via object.class) - why not the singleton (or extension) > naming the elements involved similarly (extend, extension_class, > extension_methods, etc.) would help clarify the relationship between > these concepts. But 'extend' already means something: add a module to the lookup path. The module that gets added is a completely different object from the singleton class, and you can extend an object with any number of modules, anonymous or otherwise. So there's no special identity between the 'extend' operation and the singleton class. There's a relation, in the sense that obj.extend(M) is like class << obj; include M; end, but I don't think there's any reason to name the singleton class itself in honor of the fact that there's a method called extend that operates on it, if you see what I mean. David -- David A. Black / Ruby Power and Light, LLC Ruby/Rails consulting & training: http://www.rubypal.com Coming in 2009: The Well-Grounded Rubyist (http://manning.com/black2) http://www.wishsight.com => Independent, social wishlist management!
on 01.02.2009 23:46
On Sun, Feb 1, 2009 at 7:42 PM, David A. Black <dblack@rubypal.com> wrote: [snip] > But 'extend' already means something: add a module to the lookup path. Yes - to the special lookup path shared by subclasses qua instances and clones. > The module that gets added is a completely different object from the > singleton class, and you can extend an object with any number of > modules, anonymous or otherwise. Well, yes, that's understood :) > So there's no special identity > between the 'extend' operation and the singleton class. I'm not saying there's an identity - I'm saying that extend and the singleton class are closely related concepts. > There's a > relation, in the sense that obj.extend(M) is like class << obj; > include M; end, but I don't think there's any reason to name the > singleton class itself in honor of the fact that there's a method > called extend that operates on it, if you see what I mean. I do see what you mean. However, the relationship between #extend and the singleton class is much closer than you allow. The singleton class is the thing that's extended. There are no other methods that operate exclusively on the singleton class. In fact, the singleton class springs into existence to accommodate an extend if it's not already there. On reading Trans' post, I was struck that extension_class, i.e. the site of extensions, would be a good name to unify these concepts. But I'd be happy with any name. Regards, Sean
on 02.02.2009 03:33
David A. Black wrote: > I wouldn't want to see 'extend' start to mean both adding a module to > the lookup path, and adding methods to the singleton class, depending > on the context. I guess obj.extend do ... could create an anonymous > module, though I've never had an issue with just creating it with > Module.new or using a named module. Ah, sorry I wasn't more clear. Yes, I meant it would create an anonymous module, so as to promote good coding practices. And I agree, it isn't that hard to use Module.new or name the module, nevertheless we see the singleton being used directly far too often b/c it is more convenient, even when having to define our own #singleton_method. And that's the point of the suggestion, to make it more convenient to #extend rather than #class_eval on the singleton class. Indeed (I wish I could find that article) one can make a good case that the singleton class should never have methods directly defined in it; always use a module. T.
on 02.02.2009 03:51
Sean O'halpin wrote: > On Sat, Jan 31, 2009 at 8:03 PM, Thomas Sawyer <transfire@gmail.com> > wrote: > [snip] >> >> end >> > > I like this - how do you see it working alongside the proposed > #class_extension from a while ago? > > I guess #extend would work as above (i.e. defines singleton methods on > instances), where #class_extension (or #class_extend?) methods/modules > would both extend a class and be inherited by subclasses. I forget > where the discussions on module inheritance ended up. Would you have a > #module_extend method too or would #class_extension work for both > classes and modules (in which case it should be renamed or alased)? Hey, that's a really good point. #class_extension is very much the same thing, but specifically designed to allow classes to carry the modules behavior through the class-level hierarchy. So accordingly a better name would be #class_extend. But as with the original, I still think that this doesn't convey enough of what it actually does to the inheritance chain, and likewise why #module_extend doesn't really make sense. But a concise name for #extend_and _propogate_through_the_class_hierarchy seems elusive. > I think you're onto something here - conceptually, #extend, singleton > methods and the-class-that-cannot-be-named are closely related but you > wouldn't know that from their names (or lack of them). > > Perhaps #extension_class? My goodness, when you put it like that it does seem rather obvious. I wonder why no one has ever thought of that before. T.
on 02.02.2009 13:30
Hi -- On Mon, 2 Feb 2009, Sean O'Halpin wrote: > On Sun, Feb 1, 2009 at 7:42 PM, David A. Black <dblack@rubypal.com> wrote: > > [snip] > >> But 'extend' already means something: add a module to the lookup path. > > Yes - to the special lookup path shared by subclasses qua instances and clones. I'm not sure what you mean by special. Every object has only one lookup path, and the singleton class is just placed along that path. Do you mean the special class of singleton classes of class objects? (The thing where their subclasses share the singleton methods.) > singleton class are closely related concepts. Yes, but singleton class and non-singleton class are also closely related. So are class and module, array and hash, integer and float... but I wouldn't merge their terminology :-) > other methods that operate exclusively on the singleton class. In > fact, the singleton class springs > into existence to accommodate an extend if it's not already there. But I wouldn't want to rename Class to IncludeClass, just because there's an include operation especially designed for classes. I know there's a bit more going on than that: the idea of "extending" an object's capabilities is always present, in some form, with all this per-object behavior in some form. But since there's already an #extend method, I think the term is potentially too flattening, so to speak. I'd like to be able to refer to the singleton class without seeming to refer to the process of including modules in it, which may or may not happen (via extend or include). > On reading Trans' post, I was struck that extension_class, i.e. the > site of extensions, would be a good name to unify these concepts. > But I'd be happy with any name. With the disclaimer that I consider there not to be a naming problem (except for the question of whether 'singleton class' is the right name in the class of Class objects, which grant singleton class access to their subclass objects), I'm starting to think of 'e_class'. Extension, extra, eigen... it's a duck-typed name :-) David -- David A. Black / Ruby Power and Light, LLC Ruby/Rails consulting & training: http://www.rubypal.com Coming in 2009: The Well-Grounded Rubyist (http://manning.com/black2) http://www.wishsight.com => Independent, social wishlist management!
on 02.02.2009 13:32
Hi -- On Mon, 2 Feb 2009, Thomas Sawyer wrote: > singleton being used directly far too often b/c it is more convenient, > even when having to define our own #singleton_method. And that's the > point of the suggestion, to make it more convenient to #extend rather > than #class_eval on the singleton class. Indeed (I wish I could find > that article) one can make a good case that the singleton class should > never have methods directly defined in it; always use a module. I'd be interested in seeing that article if you can find it. It doesn't strike me right off as a convincing idea, but the reasoning would be interesting to see. David -- David A. Black / Ruby Power and Light, LLC Ruby/Rails consulting & training: http://www.rubypal.com Coming in 2009: The Well-Grounded Rubyist (http://manning.com/black2) http://www.wishsight.com => Independent, social wishlist management!
on 02.02.2009 17:20
On Mon, Feb 2, 2009 at 3:33 AM, Thomas Sawyer <transfire@gmail.com> wrote: ed module. > > Ah, sorry I wasn't more clear. Yes, I meant it would create an anonymous > module, so as to promote good coding practices. And I agree, it isn't > that hard to use Module.new or name the module, nevertheless we see the > singleton being used directly far too often b/c it is more convenient, > even when having to define our own #singleton_method. And that's the > point of the suggestion, to make it more convenient to #extend rather > than #class_eval on the singleton class. Indeed (I wish I could find > that article) one can make a good case that the singleton class should > never have methods directly defined in it; always use a module. Too bad you cannot find the article. I wonder especially if the rationale behind that "dogma" was based on performance ( hopefully not ) or design principles. Cheers R.
on 02.02.2009 18:07
David A. Black wrote: > I'd be interested in seeing that article if you can find it. It > doesn't strike me right off as a convincing idea, but the reasoning > would be interesting to see. Yea I found it! http://blog.jayfields.com/2008/07/ruby-underuse-of-modules.html http://blog.jayfields.com/2008/04/extend-modules-instead-of-defining.html Should have followed my gut from the get-go. I suspected it was Jay :) T.
on 02.02.2009 18:15
On Feb 2, 2009, at 11:07 AM, Thomas Sawyer wrote: > David A. Black wrote: >> I'd be interested in seeing that article if you can find it. It >> doesn't strike me right off as a convincing idea, but the reasoning >> would be interesting to see. > > Yea I found it! > > http://blog.jayfields.com/2008/07/ruby-underuse-of-modules.html > http://blog.jayfields.com/2008/04/extend-modules-instead-of-defining.html Those are great reading. Thanks for sharing. James Edward Gray II
on 02.02.2009 20:07
Hi -- On Tue, 3 Feb 2009, Thomas Sawyer wrote: > David A. Black wrote: >> I'd be interested in seeing that article if you can find it. It >> doesn't strike me right off as a convincing idea, but the reasoning >> would be interesting to see. > > Yea I found it! > > http://blog.jayfields.com/2008/07/ruby-underuse-of-modules.html > http://blog.jayfields.com/2008/04/extend-modules-instead-of-defining.html I think it's very good advice for many situations (#extend has always been my favorite technique for changing the behavior of core objects, for example). I don't think it's necessary, though, to choose one over the other in an exclusive sense. This doesn't bother me: class C class << self def x end def y end end end etc. Jay's example with extending an object with two modules, so that the most recent one "wins" (whereas all modules "lose" if the method in question is defined in the singleton class) is very convincing, though again I wouldn't necessarily treat it as a reason never to define a method in the singleton class. I'd say it's more that you want to know what the ramifications of each technique are, and then choose the one you want. In that sense it's analogous (though not identical) to the non-singleton case, where a method defined in a class "wins", for the instances of the class, over definitions in included modules. That can be good, or not; it depends on what you're trying to do. It all comes down to mastery of the order of method lookup, which then allows you to do pretty much any permutation. David -- David A. Black / Ruby Power and Light, LLC Ruby/Rails consulting & training: http://www.rubypal.com Coming in 2009: The Well-Grounded Rubyist (http://manning.com/black2) http://www.wishsight.com => Independent, social wishlist management!
on 03.02.2009 13:53
David A. Black wrote: > etc. Jay's example with extending an object with two modules, so that > the most recent one "wins" (whereas all modules "lose" if the method > in question is defined in the singleton class) is very convincing, > though again I wouldn't necessarily treat it as a reason never to > define a method in the singleton class. I'd say it's more that you > want to know what the ramifications of each technique are, and then > choose the one you want. In that sense it's analogous (though not > identical) to the non-singleton case, where a method defined in a > class "wins", for the instances of the class, over definitions in > included modules. That can be good, or not; it depends on what you're > trying to do. > > It all comes down to mastery of the order of method lookup, which then > allows you to do pretty much any permutation. Can you think of a good example of where it is NOT good? All I can think of is when we need to metaprogram around someone else not using modules. I'm sure there are occasions to act directly on the singleton, but I've come to believe that should be the exception rather than the rule. And I think it would behoove Ruby to promote that as the common idiom. We've grown accustom to seeing "class << self". But I think it should be raising flags instead --"we are doing something very metay here". T.
on 03.02.2009 14:49
On Tue, 3 Feb 2009, Thomas Sawyer wrote: >> class "wins", for the instances of the class, over definitions in > come to believe that should be the exception rather than the rule. And I > think it would behoove Ruby to promote that as the common idiom. We've > grown accustom to seeing "class << self". But I think it should be > raising flags instead --"we are doing something very metay here". I disagree. I think that excessive meta-ness is to a large extent in the eye of the beholder. The objects don't know that there's anything "meta" about what they're being asked to do (resolve a message into a method, by searching along their lookup path), and the class keyword doesn't care whether you use the "<< obj" notation or the "MyClass" notation. Jay's example of extending an individual object twice is interesting, but I don't think I've ever actually had to do it. And the only problem is mixing the two techniques: class << obj def x end end module M def x end end obj.extend(M) # obj.x is still the first one Since you can always reopen the singleton class and redefine the method, using the singleton class in the first place doesn't mean that you're stuck with the original method definition. I think #extend is highly underutilized. It's one of my favorite Ruby techniques. I just don't feel that it has to be in a death-struggle with any other techniques. David -- David A. Black / Ruby Power and Light, LLC Ruby/Rails consulting & training: http://www.rubypal.com Coming in 2009: The Well-Grounded Rubyist (http://manning.com/black2) http://www.wishsight.com => Independent, social wishlist management!
on 03.02.2009 22:06
On Tue, Feb 3, 2009 at 2:44 PM, David A. Black <dblack@rubypal.com> wrote: > end > obj.extend(M) # obj.x is still the first one > > Since you can always reopen the singleton class and redefine the > method, using the singleton class in the first place doesn't mean that > you're stuck with the original method definition. > > I think #extend is highly underutilized. It's one of my favorite Ruby > techniques. I just don't feel that it has to be in a death-struggle > with any other techniques. Well is that not exactly what Tom meant? Maybe someone can update me here please? My understanding is that: If people would use extend instead of class << etc the "metaprogrammers" (e.g. somebody creating a framework or an extensions for traits as I did ) could produce code easier just by saying: As long as you extend your object and classes and never use << my framework is shielded. If you reopen singleton classes, well you are at your own. Cheers Robert
on 03.02.2009 22:26
Hi -- On Wed, 4 Feb 2009, Robert Dober wrote: >> end > > Well is that not exactly what Tom meant? Maybe someone can update me > here please? > My understanding is that: > > If people would use extend instead of class << etc the > "metaprogrammers" (e.g. somebody creating a framework or an extensions > for traits as I did ) could produce code easier just by saying: > As long as you extend your object and classes and never use << my > framework is shielded. If you reopen singleton classes, well you are > at your own. It depends what you mean by shielded. If I use a library that extends my objects with modules, and then I extend those same objects with other modules that have methods of the same name, then the methods in the library will be hidden. This is, however, a very unlikely scenario. But avoiding << isn't a cure-all, if the problem is that two modules are fighting over a particular method for a particular object. Nor is this kind of problem specific to singleton methods and singleton classes, of course. This is why I think it's very tricky to come up with rules in this area. In the end, it's always going to be about particular code and particular programming goals. David -- David A. Black / Ruby Power and Light, LLC Ruby/Rails consulting & training: http://www.rubypal.com Coming in 2009: The Well-Grounded Rubyist (http://manning.com/black2) http://www.wishsight.com => Independent, social wishlist management!
on 04.02.2009 08:40
On Tue, Feb 3, 2009 at 10:25 PM, David A. Black <dblack@rubypal.com> wrote: > Nor is this kind of problem specific to singleton methods and > singleton classes, of course. This is why I think it's very tricky to > come up with rules in this area. In the end, it's always going to be > about particular code and particular programming goals. Ah very nicely put, indeed that shows me what I *should* have said: It is IMHO preferable that, in case of a name conflict, the framework wins over the application using it. But maybe I am wrong and this is not much better a scenario? (All boiling down as usual to testing and testing and well... testing) Robert
on 04.02.2009 13:01
Hi -- On Wed, 4 Feb 2009, Robert Dober wrote: > not much better a scenario? To be honest, I'm having a hard time even thinking of a case when exactly this would happen. I'm trying to think what such library code would look like, and it's hard to picture a reasonable version :-) > (All boiling down as usual to testing and > testing and well... testing) Or, in other words, all boiling down to what the objects actually do when we send them messages. Funny how it always converges back onto that, isn't it? :-) David -- David A. Black / Ruby Power and Light, LLC Ruby/Rails consulting & training: http://www.rubypal.com Coming in 2009: The Well-Grounded Rubyist (http://manning.com/black2) http://www.wishsight.com => Independent, social wishlist management!