DRYing a Regex

[Rick DeNatale]

I would still look immediately to the class of the object in order to fin= d
out what it's supposed to do. From there, the class definition will proba= bly
list it's module inclusions prominently.

I've long (since at least 18 years) been an advocate of divorcing the
notion of type from class in dynamically typed languages:

http://talklikeaduck.denhaven2.com/files/TypesFromTheClientsViewpoint.PDF

IMHO, viewing a variable as a 'role' to be filled with one or more
objects is a powerful technique.

Alastair Cockburn recently told me that he still refers clients to the
reference paper, which I wrote at IBM, when he and l were both there.

The view fits into a general approach to OO design which is called
"responsibility based" or "role based" design. Rebecca Wirfs-Brock
was one of the authors who published books on the approach

http://www.amazon.com/Rebecca-Wirfs-Brock/e/B001IQXNWC/ref=3Dntt_athr_dp_pe=
l_1

This was before the static-typing crowd (starting with C++) took over
the conventional wisdom as to what it meant to be OO, in turn leading
to a proliferation of "methodologies" using static typing.

Those of us in the dynamic typing/roles/responsibility based community
see this as an unfortunate parallel to Gresham's Law.

With the re-birth of interest in dynamically typed languages I think
that the role based view is preferable.

--=20
Rick DeNatale

Blog: http://talklikeaduck.denhaven2.com/
Twitter: http://twitter.com/RickDeNatale
WWR: http://www.workingwithrails.com/person/9021-rick-denatale
LinkedIn: http://www.linkedin.com/in/rickdenatale

 

[James Edward Gray II]

(Note: In this case, it appears Og _always_ handles the
request via method_missing. But I've seen other code
in Og (or maybe Nitro) that did *define* the method when
it was first called, such that on subsequent invocations
the method would now already be existing.)

ActiveRecord from Rails works this way. If you would like to see the =
code it starts around line 1830 of this file:

=
http://github.com/rails/rails/blob/master/activerecord/lib/active_record/b=
ase.rb

I seem to recall mention awhile back on ruby-talk of
a gem or module that integrated `ri` into `irb`, such
that one could pull up the documentation from within
irb. (I don't have any links for that, sorry.)

Here's what I have in my .irbrc file:

def ri(*names)
system(%{ri #{names.join(" ")}})
end

James Edward Gray II

 

[James Edward Gray II]

James Edward Gray II wrote:
[...]

=20
I would like to see us move away from considering classes to be types = at=20
all in Ruby. Who knows what modules an object has mixed into it and = who=20
knows what singleton methods are defined on it.

=20
Do you make much use of singleton mixins or singleton methods in your=20=

code? I know I don't.

I have been doing a lot more of mixing modules into individual objects, =
yes. I have been more than pleased with the results too. I think it's =
something we should all try to do more of. I gave a speech about this =
at LSRC this year which should show up here someday:

http://lsrc2009.confreaks.com/

I can give a couple of examples.

I recently ran across some code that had extensions to a core system. =
Each extension would reopen the core classes and edit away. =
Unfortunately, they had to duplicate a lot of the core code to make =
little changes to it. I rewrote the code to allow extensions to =
register modules with the core classes. Then when those classes =
produced objects, they would mix in any registered modules. This simple =
eliminated almost all of the duplication, because the modules were in =
the singleton class *in front of* the methods they were modifying. They =
could read the arguments and see if they needed to step in with their =
modified behavior, or just hand off to super().

I showed another example in my talk where I was trying to create a one =
instance configuration object. Originally I did it with a constant and =
some clever reopening of the singleton class, but that caused problems =
like not being able to easily document this object's API. I switched to =
just creating the one instance I needed and immediately mixing in a =
module that added the special functionality and it solved all the =
problems I had. You can document a module just fine. (The example is =
in my slides, if you want to see it: =
http://blog.grayproductions.net/articles/lone_star_rubyconf_slides.)

I think we should do more of this. For example, I think we could return =
an Array that mixes in a Paginated module instead of a =
PaginatedCollection object that inherits from Array. That feels more =
right to me. It's an Array and it has some extra functionality added in =
related to pagination. The uses go on and on.

=20
You're right. But with a proper class system, my point about not=20
needing Apps Hungarian in Ruby still stands, I think. Do you =

disagree?

I was agreeing with you, yes. I was saying that adding an a_ or s_ to =
the beginning of a variable name, assumably to indicate Array or String, =
is a damaging practice, because that's not necessarily all you need to =
know about the object. I think it promotes the wrong kind of thinking =
about Ruby's types.

James Edward Gray II

 

[James Edward Gray II]

at all in Ruby. Who knows what modules an object has mixed into it and =
who knows what singleton methods are defined on it. A class, which is =
what people traditionally take for the type, is just one piece of an =
object's identity.

=20
I would still look immediately to the class of the object in order to =

find out what it's supposed to do. =46rom there, the class definition =
will probably list it's module inclusions prominently.

Sure, it's definitely part of the picture.

As a vim user, with very limited interactive debugging, my primary =

exploration technique will usually consist of at most a couple of =
'obj.methods.grep' calls followed by grepping ~/gems which seems to =
emphasize the actual reading of the source for object identity info.

Your use of grep() for methods catches a lot of things a class =
definition might not tell you.

I'm curious what you think the most correct way is to discover object =

identity.

Well, if we just mix modules into objects as I recommended in my =
previous message, Ruby's type system just naturally handles all of the =
details.
=3D> [Magical, Object, Kernel]

James Edward Gray II

 

[David A. Black]

Hi --

James Edward Gray II wrote:
[...]

I would like to see us move away from considering classes to be types at
all in Ruby. Who knows what modules an object has mixed into it and who
knows what singleton methods are defined on it.

Do you make much use of singleton mixins or singleton methods in your
code? I know I don't.

I write class methods sometimes (I know those are singleton with an
asterisk next to them, but still), and I think that extending core
objects with modules is a frequently overlooked and very powerful
alternative to reopening core classes and adding methods.

This kind of thing:

class String
def method_I_need_once_or_twice
...

is almost always overkill. It's sort of the core-functionality
counterpart of using global variables. Extending an object is a much
more precise operation -- and has the additional merit, I find, of
really making you think about whether it's worth bothering to the
extend the object instead of working with what the object can already
do.


David

--
The Ruby training with D. Black, G. Brown, J.McAnally
Compleat Jan 22-23, 2010, Tampa, FL
Rubyist http://www.thecompleatrubyist.com

David A. Black/Ruby Power and Light, LLC (http://www.rubypal.com)

 

[David A. Black]

Hi --

A human looking to documentation to find out what an object
of a partiular class is supposed to *do*, is one thing. But
then there's the programmatic flipside where one could code
a method to select between different behaviors based on the
class-type of a given argument-object.

def foo(bar)
if bar.is_a? Array
do_array_thing(bar)
elsif bar.is_a? String
do_string_thing(bar)
else
... # ?
end
end

I believe it's (variations on) the above that are viewed
as unreasonably restrictive in ruby.

It's challenging, too, because even :respond_to? can be
misleading.

Indeed:

$ ./script/console
Loading development environment (Rails 2.3.3)=> #<Container id: 1, name: "stuff", created_at: "2009-09-14
20:51:19", updated_at: "2009-09-14 20:51:19">=> [#<Item id: 345698075, collection_id: 1, created_at: "2009-09-16
22:29:41", updated_at: "2009-09-16 22:47:27", description: "abc">]ActiveRecord::RecordNotFound: Couldn't find Item without an ID

Here, it's all about the documented interface, not the class name and
not the method names.


David

--
The Ruby training with D. Black, G. Brown, J.McAnally
Compleat Jan 22-23, 2010, Tampa, FL
Rubyist http://www.thecompleatrubyist.com

David A. Black/Ruby Power and Light, LLC (http://www.rubypal.com)

 

[Marnen Laibow-Koser]

James Edward Gray II wrote:
[...]

Here's what I have in my .irbrc file:

def ri(*names)
system(%{ri #{names.join(" ")}})
end

James Edward Gray II

Great idea!

Best,

 

[Marnen Laibow-Koser]

I have been doing a lot more of mixing modules into individual objects,
yes. I have been more than pleased with the results too. I think it's
something we should all try to do more of.

How do you keep such code maintainable? It seems to me that
circumventing the class system on a regular basis makes it harder to
tell what's what.

I gave a speech about this
at LSRC this year which should show up here someday:

http://lsrc2009.confreaks.com/

I can give a couple of examples.

I recently ran across some code that had extensions to a core system.
Each extension would reopen the core classes and edit away.
Unfortunately, they had to duplicate a lot of the core code to make
little changes to it. I rewrote the code to allow extensions to
register modules with the core classes. Then when those classes
produced objects, they would mix in any registered modules. This simple
eliminated almost all of the duplication, because the modules were in
the singleton class *in front of* the methods they were modifying. They
could read the arguments and see if they needed to step in with their
modified behavior, or just hand off to super().

Yes, I can see how this would be useful to modify singleton objects.
But where a class has more than one or two instances, wouldn't this be
extremely confusing?

I showed another example in my talk where I was trying to create a one
instance configuration object. Originally I did it with a constant and
some clever reopening of the singleton class, but that caused problems
like not being able to easily document this object's API. I switched to
just creating the one instance I needed and immediately mixing in a
module that added the special functionality and it solved all the
problems I had. You can document a module just fine. (The example is
in my slides, if you want to see it:
http://blog.grayproductions.net/articles/lone_star_rubyconf_slides.)

I'll take a look.

I think we should do more of this. For example, I think we could return
an Array that mixes in a Paginated module instead of a
PaginatedCollection object that inherits from Array. That feels more
right to me. It's an Array and it has some extra functionality added in
related to pagination. The uses go on and on.

That feels hackish to me. If a common type like Array -- of which there
could be hundreds of instances in a typical program -- needs extra
functionality on some instances, it seems clearer and more
intention-revealing to subclass it. Where's the benefit of the
singleton mixin here?

I was agreeing with you, yes. I was saying that adding an a_ or s_ to
the beginning of a variable name, assumably to indicate Array or String,
is a damaging practice, because that's not necessarily all you need to
know about the object. I think it promotes the wrong kind of thinking
about Ruby's types.

That's Systems Hungarian. Check out Joel's article if you haven't
already.

Best,

 

[Marnen Laibow-Koser]

David A. Black wrote:
[...]

I write class methods sometimes (I know those are singleton with an
asterisk next to them, but still),

Sometimes they're the right thing...

and I think that extending core
objects with modules is a frequently overlooked and very powerful
alternative to reopening core classes and adding methods.

This kind of thing:

class String
def method_I_need_once_or_twice
...

is almost always overkill. It's sort of the core-functionality
counterpart of using global variables.

True. (Even though I occasionally do this.)

Extending an object is a much
more precise operation -- and has the additional merit, I find, of
really making you think about whether it's worth bothering to the
extend the object instead of working with what the object can already
do.

Agreed. But why is it worth extending an object instead of subclassing
it?

In other words,
class SpecialString < String
def method_I_need_once_or_twice
...
end
...
@some_string = SpecialString.new(@some_string)

seems to me like the right way to do this -- you can check if a given
String instance is a SpecialString or a plain String, or simply use
overriding and polymorphism for delegation.

Yet, if I understand you correctly, you and James are claiming that it
is preferable to do
class << @some_string
def method_I_need_once_or_twice
end

Do I understand correctly? If so, why? I hesitate to contradict such
experts as you and James, but I'm really not seeing the benefit. For
one thing, type-checking completely falls down with this pattern.
Polymorphism may or may not, depending on how it's implemented. And I
don't see a single advantage that we get in return for the loss of
type-checking. What am I missing?

Best,

 

[James Edward Gray II]

=20
How do you keep such code maintainable? It seems to me that=20
circumventing the class system on a regular basis makes it harder to=20=

tell what's what.

Well, I've said that I don't consider the class system a definition of =
my types. This is why.

Honestly, I haven't had trouble with the approach yet. I can still do =
an is_a?() check for either the class or the mixed in modules, if I need =
to check what something can do.

I don't consider this circumventing Ruby's type system. Ruby's type =
system handles mixed in modules just fine. We just tend to think of the =
inheritance hierarchy as types. Ruby has a more open definition than =
that.

Perhaps I'll eventually run into a situation where I regret handling it =
by mixing modules into objects. I promise to admit it when I do. Until =
then though, all of my experiences with it have been very positive.

Yes, I can see how this would be useful to modify singleton objects.=20=

But where a class has more than one or two instances, wouldn't this be=20=

extremely confusing?

More confusing than trying to figure out where some code reopened the =
class you are looking at and rewrote a method to change it's behavior? =
Not to me. At least Ruby will tell me about mixed in modules!

=20
That feels hackish to me. If a common type like Array -- of which = there=20
could be hundreds of instances in a typical program -- needs extra=20
functionality on some instances, it seems clearer and more=20
intention-revealing to subclass it. Where's the benefit of the=20
singleton mixin here?

Where's the benefit of subclassing? I thought it was pretty well =
accepted that subclassing is pretty tight coupling and can be pretty =
fragile. Many Design Patterns are about avoiding subclassing for just =
that reason, right?

If you subclass, you've already made some heavy decisions. You are =
saying pagination returns a special Array. What do you do when I want a =
paginated SortedSet (from Ruby's standard library)? You will be pretty =
much starting over, building another specialized subclass, I assume. =
I'll be thinking, "What changes does my Paginated module need to support =
SortedSet?" I would rather be in that position, that's all.

=20
That's Systems Hungarian. Check out Joel's article if you haven't=20
already.

Yes, I've read it. I'm still agreeing with you.

My examples, a and s for (I assume) Array and String, are the actual =
examples that started this discussion. That's what I feel should be =
discouraged and, yes, it's called Systems Hungarian.

I can see a little value in Apps Hungarian, but, again agreeing with =
you, I would rather build the protection into the code than the variable =
names. Or just teach the code to do the right thing, like converting to =
a common measurement and then combining values.

I do see that I quoted pretty badly above though, which is probably what =
made this so confusing. Sorry!

James Edward Gray II

 

[James Edward Gray II]

But why is it worth extending an object instead of subclassing it?
=20
In other words,
class SpecialString < String
def method_I_need_once_or_twice
...
end
...
@some_string =3D SpecialString.new(@some_string)
=20
seems to me like the right way to do this -- you can check if a given=20=

String instance is a SpecialString or a plain String, or simply use=20
overriding and polymorphism for delegation.

If you mix a module into the String, you can still use is_a?() to check =
for that module. It can also override methods. The object is still =
polymorphic. I'm not understanding the advantages you think we are =
losing.

Yet, if I understand you correctly, you and James are claiming that it=20=

is preferable to do
class << @some_string
def method_I_need_once_or_twice
end
=20
Do I understand correctly?

I would much prefer to mix a module into the object. It has all the =
advantages of changing a singleton class, but it participates in the =
type system, can be read by RDoc, etc.

If so, why?

Hopefully I've made my case by now, but just to sum it up one more time: =
I think it's more flexible than subclassing, it does participate in the =
type system, it can be documented. I'm not seeing the minuses.

James Edward Gray II=

 

[Marnen Laibow-Koser]

If you mix a module into the String, you can still use is_a?() to check
for that module. It can also override methods. The object is still
polymorphic. I'm not understanding the advantages you think we are
losing.


I would much prefer to mix a module into the object. It has all the
advantages of changing a singleton class, but it participates in the
type system, can be read by RDoc, etc.

OK. That makes more sense to me than the sample I gave.

Hopefully I've made my case by now, but just to sum it up one more time:
I think it's more flexible than subclassing,

Even subclassing like
class SpecialString < String
include SpecialModule
end
?

It seems to me that this is the best of both worlds.

it does participate in the
type system,

True. I hadn't considered singleton module inclusion as completely as I
should have.

it can be documented.

How can it be documented? In the example I gave above, the rdoc for
SpecialString will say that it includes SpecialModule. I don't see how
to do that with a singleton mixin.

I'm not seeing the minuses.

Start with the lack of documentation.

Also, I admit that something feels deeply *wrong* to me about extending
individual objects (on more than an occasional basis) without changing
their nominal class. I think a class is still a useful construct, but
too much singleton manipulation renders it meaningless -- a class seems
to me like a rule for how an object will act, and singleton manipulation
creates too many exceptions to the rules. That feels like sloppy,
unstructured programming to me, although I'll be interested to try the
pattern in practice and see what comes of it.

James Edward Gray II

Best,

 

[James Edward Gray II]

=20
Even subclassing like
class SpecialString < String
include SpecialModule
end
?
=20
It seems to me that this is the best of both worlds.

It seems to me like an extra step that isn't needed.

Obviously, this does work too, yes.

About the only downside I can think of now is that using this technique, =
I need to be in control of the code where the object is created. In =
other words, I need to make sure that code does SpecialString.new() =
instead of String.new() (or using a String literal). I guess I could =
still mix the module into an object after the fact, but that raises the =
excellent question of what is the class doing here?

=20
How can it be documented? In the example I gave above, the rdoc for=20=

SpecialString will say that it includes SpecialModule. I don't see = how=20
to do that with a singleton mixin.

It fits into RDoc comments naturally:

# Returns an Array enhanced by the Paginated module.
def paginate(=85)
=85
end

# This module is used to add pagination support to objects=85
module Paginated
=85
end

=20
Start with the lack of documentation.

OK, I answered that.

Now you answer the question you ignored, what about the well-known issue =
of inheritance producing tight coupling. Here's a link to a good =
description of the problem, from a Java point of view:

http://www.javaworld.com/javaworld/jw-08-2003/jw-0801-toolbox.html

James Edward Gray II

 

[Marnen Laibow-Koser]

It seems to me like an extra step that isn't needed.

Obviously, this does work too, yes.

About the only downside I can think of now is that using this technique,
I need to be in control of the code where the object is created. In
other words, I need to make sure that code does SpecialString.new()
instead of String.new() (or using a String literal). I guess I could
still mix the module into an object after the fact, but that raises the
excellent question of what is the class doing here?

I think I can answer this question, but the perspective from which
you're asking is unclear.

It fits into RDoc comments naturally:

# Returns an Array enhanced by the Paginated module.
def paginate(�)
�
end

# This module is used to add pagination support to objects�
module Paginated
�
end

Yes, of course. I was asking more about automatic documentation such as
RDoc picks up for included modules.

But I tend to be pretty conscientious about writing doc comments for
methods.

OK, I answered that.

Now you answer the question you ignored, what about the well-known issue
of inheritance producing tight coupling. Here's a link to a good
description of the problem, from a Java point of view:

http://www.javaworld.com/javaworld/jw-08-2003/jw-0801-toolbox.html

I'm not ignoring it. I'm just not really convinced that it's a problem.
In cases where inheritance is called for, I'm not sure tight coupling is
inappropriate. If tight coupling is inappropriate in a given case,
perhaps that's a sign that composition or module inclusion should be
used. If SpecialString is a decorated String, I don't see too much
reason for decoupling from String.

I will consider this further and read the article, though. I'm far from
certain that I'm right on this point.

Now, what about the sloppiness of creating too many exceptions?

Best,

 

[James Edward Gray II]

I'm far from certain that I'm right on this point.

I'm not sure I'm write either. It just seems to be working well for me =
so far.

James Edward Gray II=

 

[Marnen Laibow-Koser]

James Edward Gray II wrote:
[...]

Now you answer the question you ignored, what about the well-known issue
of inheritance producing tight coupling. Here's a link to a good
description of the problem, from a Java point of view:

http://www.javaworld.com/javaworld/jw-08-2003/jw-0801-toolbox.html

Oh, Allen Holub. This is the same guy who thinks that MVC is not
object-oriented (see http://c2.com/cgi/wiki?MvcIsNotObjectOriented for
discussion and link to original article). Anyway, Holub's argument --
that one should code to interfaces, not classes -- means a lot to
programming style in Java, but very little to programming style in Ruby,
I think, precisely because Ruby is dynamically typed. You don't have to
declare typed variables in Ruby, and you're generally not even
interested in the type of an object in Ruby, because Ruby's duck-typing
means you don't care.

You know all this, of course. But I don't think you appreciate that it
basically renders meaningless the "flexibility" part of Holub's thesis.
His examples are good in Java, but not in Ruby.

Consider the Ruby version of Holub's first "bad" Java example:
def f
@list = LinkedList.new
g(@list)
end

def g(list)
list.add(...)
g2(list)
end

Unlike in Java, g doesn't need to assume anything about its argument
except that it won't complain when it receives an :add message. We
could change the type of @list completely and g would not break in Ruby,
as long as the new object can handle an :add message.

Likewise, Holub's first alleged example of the coupling problem is
nothing of the kind. The problem with his Stack class isn't that it
uses implementation inheritance -- it's that it uses implementation
inheritance *inappropriately*, by exposing a public method in the base
class that will leave the derived class in an inconsistent state.
That's just a plain bug. In this case, composition should have been
used instead of inheritance (yes, I wrote that before reading that it
was Holub's suggested solution too!). It's like using a hammer to drive
a screw -- the fact that it doesn't work very well means that it's the
*wrong* tool, not a *generally bad* tool.

The Monitorable_stack example is certainly a better example of the
fragile base class problem. But I don't think it's fixable with
interface inheritance. Apparently, neither does Holub: his supposedly
"interface-based" rewrite is actually composition-based (notice the
Monitorable_stack.stack member), and would work just as well if no
interfaces were involved. I will be charitable and assume that Holub
was merely being sloppy here, not deliberately intellectually dishonest.
Either way, it does nothing to advance his argument in favor of
interfaces.

This article is appallingly poorly thought out, and in any case only
warns against using typed arguments (hardly possible anyway in Ruby) and
using inheritance where composition was actually necessary (a basic OO
analysis mistake). It brings little or nothing useful to the present
discussion.

James Edward Gray II

Best,

 

[Phrogz]

I would like to see us move away from considering classes to be types at all in Ruby.
Who knows what modules an object has mixed into it and who knows what singleton
methods are defined on it.  A class, which is what people traditionallytake for the
type, is just one piece of an object's identity.

Ill-formed thoughts on this:
a) Duck-Typing FTW
b) Even Google buys duck-typing, albeit in a more formalized way:
http://golang.org/doc/go_lang_faq.html#inheritance

 

[James Edward Gray II]

This article is appallingly poorly thought out, and in any case only=20=

warns against using typed arguments (hardly possible anyway in Ruby) = and=20
using inheritance where composition was actually necessary (a basic OO=20=

analysis mistake). It brings little or nothing useful to the present=20=

discussion.

I chose an example of the discussion. It is in no way isolated. The =
Gang of Four book is largely about avoiding inheritance. James Gosling =
admits that he wishes he could do away with objects for typing in Java, =
as the article says. You even stated that types aren't all that =
important in Ruby, which I agree with, but that seems like and argument =
against all of your examples that handle all typing with subclassing.

Anyway, I've given examples and provided reference points. I hope I've =
made my case. Now we're probably just bugging people, so I'm going to =
let it go.

James Edward Gray II=

 

[Marnen Laibow-Koser]

I chose an example of the discussion.

Unfortunately, it's a terrible example. A poorly reasoned, marginally
relevant article from an untrustworthy source is not really going to
convince anyone (at least, it shouldn't). I have been trying to read
Rick's article, but it always seems to take forever to download.

It is in no way isolated. The
Gang of Four book is largely about avoiding inheritance.

Really? My memory from when I read the GoF book is that many of the
patterns (certainly not all) use inheritance as a basic building block.

A check through the GoF pattern pages on Wikipedia, however, shows that
I may be mistaken. Many of the cases I had remembered as inheritance
are actually implementation of an interface, and most of the others are
inheritance from abstract classes (which are sort of another kind of
interface).

Then again, while I appreciate the concepts inherent in the GoF
patterns, I don't find those 23 patterns popping up all that much in the
code I write. I wonder why. (For the most part, I don't deliberately
try to code or refactor to GoF patterns, but if they want to emerge from
refactoring, I certainly won't stand in their way.)

James Gosling
admits that he wishes he could do away with objects for typing in Java,
as the article says. You even stated that types aren't all that
important in Ruby, which I agree with, but that seems like and argument
against all of your examples that handle all typing with subclassing.

Perhaps so. I like Ruby's duck-typing, but I don't seem to be willing
to use it as a replacement for conventional inheritance. I seem to
believe that it works best as a complement to a traditional type
hierarchy. But these are semi-conscious attitudes.

Maybe that means I don't know how to use duck typing properly. I have
to think about this some more.

Anyway, I've given examples and provided reference points. I hope I've
made my case. Now we're probably just bugging people, so I'm going to
let it go.

What's to let go? I don't think we're off topic for the list...

James Edward Gray II

Best,

 

[David A. Black]

Hi --

David A. Black wrote:
[...]

I write class methods sometimes (I know those are singleton with an
asterisk next to them, but still),

Sometimes they're the right thing...

and I think that extending core
objects with modules is a frequently overlooked and very powerful
alternative to reopening core classes and adding methods.

This kind of thing:

class String
def method_I_need_once_or_twice
...

is almost always overkill. It's sort of the core-functionality
counterpart of using global variables.

True. (Even though I occasionally do this.)

Extending an object is a much
more precise operation -- and has the additional merit, I find, of
really making you think about whether it's worth bothering to the
extend the object instead of working with what the object can already
do.

Agreed. But why is it worth extending an object instead of subclassing
it?

In other words,
class SpecialString < String
def method_I_need_once_or_twice
...
end
...
@some_string = SpecialString.new(@some_string)

seems to me like the right way to do this -- you can check if a given
String instance is a SpecialString or a plain String, or simply use
overriding and polymorphism for delegation.

Yet, if I understand you correctly, you and James are claiming that it
is preferable to do
class << @some_string
def method_I_need_once_or_twice
end

Do I understand correctly? If so, why? I hesitate to contradict such
experts as you and James, but I'm really not seeing the benefit. For
one thing, type-checking completely falls down with this pattern.
Polymorphism may or may not, depending on how it's implemented. And I
don't see a single advantage that we get in return for the loss of
type-checking. What am I missing?

I'm not saying (and I don't think James would say) that this is a
"winner-take-all" situation where we all have to choose one technique
and do only that. But I think extending core objects is a very good
way to add functionality to them.

It sounds like by type-checking you mean class-checking (or
ancestry-checking). It's kind of a circular argument, in the sense
that if you decide that it's important to know an object's class
because you're relying on that to tell you exactly what the object
does, then it's bad if the object does other stuff (i.e., if its type
diverges from its class).

It's certainly possible to look at things that way, but it seems to me
that it means you're fighting Ruby. The entire thrust of Ruby's object
model is to put the focus on the objects rather than their classes.
(Yes, I know that classes are objects Them too -- which is why
class methods are manifested as singleton methods on class objects,
rather than some completely separate language-level construct.)

Here's one of my favorite historical observations about Ruby, where
ruby10 is the Ruby 1.0 interpreter:

[dblack@ruby-versions ~]$ ruby10 -e 'puts "hi"'-e:1: NameError:
undefined method `puts' for main(Object)
[dblack@ruby-versions ~]$ ruby10 -e 'a = "hi"; class << a; def talk;
print self + "!\n"; end; end; a.talk'
hi!

In other words, Ruby 1.0 had no puts statement... but it *did* have
singleton classes. That's a great corrective to the perception I think
some people have that singleton behaviors are some kind of
meta-wizard-add-on complication to the language. They're not; the
language was designed from the beginning to make it possible to
engineer objects on an individual basis.

I've heard people say that, while that's true, it's undisciplined to
actually use any of these techniques. I disagree radically. Of course,
I don't spend all that much of my time as a Ruby programmer writing
singleton methods -- but I do regard the individual object as the
center of gravity, and I regard classes largely as a convenience-macro
for creating objects bundled with certain behaviors at their birth
that may or may not represent what they do during their lifetimes.

This is also why, in my book and in my training, I present singleton
methods *first*, and classes second. (And I completely understand why
Matt Neuberg introduces modules before classes[1] -- which I usually
don't but it's an extremely intriguing idea.)

Classes exist in Ruby, and no one is awarding points based on how many
singleton methods one writes. But for me, anyway, the class part of
the model floats on top of the real business, which is the objects. So
I don't like to commit myself to having things break just because
objects aren't aligned perfectly type-to-class.

(There's more to say but that's long enough for now


David

[1] http://www.apeth.com/rbappscript/02justenoughruby.html