[#3986] Re: Principle of least effort -- another Ruby virtue. — Andrew Hunt <andy@...>

> Principle of Least Effort.

14 messages 2000/07/14

[#4043] What are you using Ruby for? — Dave Thomas <Dave@...>

16 messages 2000/07/16

[#4139] Facilitating Ruby self-propagation with the rig-it autopolymorph application. — Conrad Schneiker <schneik@...>

Hi,

11 messages 2000/07/20

[ruby-talk:04067] Re: Pluggable functions and blocks

From: matz@... (Yukihiro Matsumoto)
Date: 2000-07-17 05:52:09 UTC
List: ruby-talk #4067
Hi,

In message "[ruby-talk:04039] Re: Pluggable functions and blocks"
    on 00/07/15, Dave Thomas <Dave@thomases.com> writes:

|Works great, but I'm wondering. That mixed parameter list doesn't seem 
|very elegant. How about keeping on with the current rule: you can only 
|call a Method object, one that's bound to a receiver. Then provide
|UnboundMethod#bind_to, which returns a Method. Then you'd rewire the
|above as
|
|     unbound = String.instance_method(:gsub)
|     unbound.bind_to("abc").call(/a/, "b") # => "bbc"

Well, this looks cooler.  I'll change the spec.

|You could then provide the symetrical Method#unbind
|
|     bound = "abc".method(:gsub)
|     unbound = bound.unbind   # => UnboundMethod
|
|This all seems to have a clearer semantic, and also allows you to
|change the state of method objects on the fly.

I made `unbound' method exactly do the same.  Is `unbind' is better
name for it?

|Anyway, I know what you're doing really. You're just trying to make
|sure that we _never_ get this book finished ;-)

The 3rd principle of software release:

  A great motivation to improve software is caused by declaring
  feature freeze.

But you can leave them undocumented; leave them to 1.7.

							matz.

In This Thread

Prev Next