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?
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.
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.
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
(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!
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?
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?
I've fixed the link (thanks for pointing it out). The other packages
are called class-in-state and import_module (both in RAA).
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).