Should every method have a module method?

[Trans]

I'm looking at some the Rail's support methods to see what Facets can
gain from it. The following gives me pause (slightly simplified for
your inspection):

| module Inflector
| extend self
|
| def pluralize(word)
| result = word.to_s.dup
| plural_rules.each do |(rule, replacement)|
| break if result.gsub!(rule, replacement)
| end
| return result
| end
| ...
|
|
| class String
| module Inflections
| def pluralize
| Inflector.pluralize(self)
| end
| ...
|
| class String
| include Inflections
| end

Is all this really neccessary? Are these methods really ever usful for
anything else but Strings and derivatives thereof? --What would you
include them in? And would you ever really be more inclined to write:

Inflector.pluralize(a)

over

a.pluralize

Perhaps some people use Ruby in completely non-OOP ways. I guess they
would appriciate this design. If so should that be something we should
always try to accomodate?

Thanks,
T

 

[Jeremy Kemper]

Is all this really neccessary? Are these methods really ever usful for
anything else but Strings and derivatives thereof? --What would you
include them in? And would you ever really be more inclined to write:
Inflector.pluralize(a) over a.pluralize

Perhaps some people use Ruby in completely non-OOP ways. I guess they
would appriciate this design. If so should that be something we should
always try to accomodate?

This is a picture of backward compatibility. The Inflector module was
used internally before deciding, months later, that its behavior is
generally useful for String.

But why was it in a module in the first place? Because we only needed
these methods for Rails and didn't want to bloat up String's public
interface. There are no 'friend' methods or means to extend String only
within a given module/namespace. The ability to extend base classes
within a namespace (and indeed, a clearer distinction between namespaces
and modules) would be useful, but I think it could be a misfeature that
increases complexity and hurts Ruby.

jeremy

 

[David A. Black]

Hi --

I'm looking at some the Rail's support methods to see what Facets can
gain from it. The following gives me pause (slightly simplified for
your inspection):

| module Inflector
| extend self
|
| def pluralize(word)
| result = word.to_s.dup
| plural_rules.each do |(rule, replacement)|
| break if result.gsub!(rule, replacement)
| end
| return result
| end
| ...
|
|
| class String
| module Inflections
| def pluralize
| Inflector.pluralize(self)
| end
| ...
|
| class String
| include Inflections
| end

(Small request: can you not put | at the beginning of code lines? It
makes them hard to cut-and-paste. Just indenting is fine.)

Is all this really neccessary? Are these methods really ever usful for
anything else but Strings and derivatives thereof? --What would you
include them in? And would you ever really be more inclined to write:

Inflector.pluralize(a)

over

a.pluralize

Perhaps some people use Ruby in completely non-OOP ways. I guess they
would appriciate this design. If so should that be something we should
always try to accomodate?

It's not strictly a OOP/non-OOP thing; it's a clash thing. It's the
same old "prisoner's dilemma"-esque problem as always: if we all agree
on what core changes can be made dynamically, we can make them, but if
we don't, we can't safely make any.

This was one of the first things I worked on when I got interested in
Ruby, and the result was the almost-proof-of-concept project Ruby
Behaviors, which offered a mechanism for block-scoped changes to the
core language. It wasn't thread-safe, though. There are some other
similar packages that do similar things, one of which I believe is
thread-safe. And Matz has been talking about some kind of namespace
facility in Ruby 2.0 to allow for this kind of thing too.


David

 

[Trans]

Could one use subclasses in a manner of temporary delegation?

| class String
| def inflect
| return Inflection.new(self)
| end
|
| class Inflection < self
| def initialize( delegate )
| super( delegate )
| @delegate = delegate
| end
| def plural
| result = word.to_s.dup
| plural_rules.each do |(rule, replacement)|
| break if result.gsub!(rule, replacement)
| end
| return result
| end
| end
|
| end

Then

| s = "dog"
| s.inflect.class #=> Inflection
| s.inflect.plural #=> "dogs"
| s.inflect.plural.class #=> String

T

 

[Trans]

(Small request: can you not put | at the beginning of code

lines? It makes them hard to cut-and-paste. Just indenting
is fine.)

I wish it were as simple. I'm using Google Groups and if I don't put
the '|' the indention is lost :-(. I've written Google twice about it,
I know thay have a fixed-font option on Google's own groups, so I
imagine they would have the same thing for Usenet mirror groups. But
alas they never respond to my requests.
Believe me, I wish they'd fix this bug!

T

 

[Pit Capitain]

This was one of the first things I worked on when I got interested in
Ruby, and the result was the almost-proof-of-concept project Ruby
Behaviors, which offered a mechanism for block-scoped changes to the
core language. It wasn't thread-safe, though. There are some other
similar packages that do similar things, one of which I believe is
thread-safe. And Matz has been talking about some kind of namespace
facility in Ruby 2.0 to allow for this kind of thing too.

Hallo David,

is your Behaviors package available somewhere? (The link in RAA isn't valid
anymore.) Do you have a little bit more information about the other packages you
were talking about?

Thanks in advance,
Pit

 

[David A. Black]

Hi --

Hallo David,

is your Behaviors package available somewhere? (The link in RAA isn't valid
anymore.) Do you have a little bit more information about the other packages
you were talking about?

I've fixed the link (thanks for pointing it out). The other packages
are called class-in-state and import_module (both in RAA).


David

 

[Pit Capitain]

I've fixed the link (thanks for pointing it out). The other packages
are called class-in-state and import_module (both in RAA).

Vielen Dank!
Pit