From: dblack@... Date: 2007-06-22T06:45:38+09:00 Subject: Re: Error in ancestor? Hi -- On Fri, 22 Jun 2007, Rick DeNatale wrote: > On 6/19/07, dblack@wobblini.net wrote: > >> On Wed, 20 Jun 2007, Rick DeNatale wrote: > >> > Coming from a background in Smalltalk, my preference would be if this >> > machinery were more visible and official, but Matz has his reasons for >> > not doing so. For one thing, not documenting it, and hiding it from >> > methods like ancestors and class makes it easier to tinker with as the >> > language evolves without "officially" breaking backward compatibility. >> >> Does that mean that no one who's ever used Smalltalk can ever think >> that it's right for Ruby to deviate from Smalltalk? :-) > > Well David, > > In short, NO. > > Yesterday I was mulling over three or four topics to write about, your post > tipped me over, so after a day of thought and editting the longish: > > http://talklikeaduck.denhaven2.com/articles/2007/06/21/where-i-come-from Cool -- I'm glad. (BTW there's an unclosed emphasis tag or something, causing about the last 1/3 to be in bold.) The points at the end are especially interesting, about metaprogramming and such in Ruby as opposed to Smalltalk, and Alan Kay's comment "that he was disappointed that so few Smalltalkers experimented with changing and extending Smalltalk by building off of the mechanisms of Class, Metaclass, and Behavior." I've actually been, perhaps not disappointed but puzzled, at the form some of this activity takes -- or doesn't take -- in the Ruby world. In particular, the needle sometimes seems to be stuck in the groove of certain ways of looking at the matter of changing and/or amending the behavior of core-class objects. People are definitely interested, for example, in the idea of having a way to do block-scoped (or something-scoped) modifications to core classes; but I think I've literally never heard anyone report actually having used any of the libraries that let one do this. And in my opinion 'extend' is massively underutilized; it really could be the answer to almost every case of wanting to have, say, an Array that can shuffle itself, or whatever. As for singleton classes: I still strongly root for Kernel#singleton_class. I find that people understand the whole thing quite readily when it's explained to them that every object has (a) a "birth" class and (b) a class of its own where it can stash methods that only it can call. And it all falls into place except that you have to go through the class << self; self; end thing to get at the class, and that makes it feel like a second-class (ha ha) citizen. (Hmmm... therein might lie another essay.... :-) 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)