Hi --

On Fri, 22 Jun 2007, Rick DeNatale wrote:

> On 6/19/07, dblack / wobblini.net <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)