Extending a core class cleanly [noobish alert]

Assume I'd like to create a statistics package designed to work on
Arrays [but see P.S.]. One way to do this would be to create functions
that take an array as an argument:

  def mean(array)
    return NaN unless array && array.size > 0
    array.reduce(0.0) {|accum, val| accum + val} / array.size
  end

... but that's so old school. What I'd really like is to *cleanly*
extend the Array class so you can operate on it directly, as in:

  >> [1, 2, 3].mean
  => 2.0

I'm sure that it's considered bad style to simply open the Array class
and extend it, since that can lead to unexpected user surprises:

  class Array
    def mean
      return NaN unless self.size > 0
      self.reduce(0.0) {|accum, val| accum + val} / self.size
    end
  end

My hunch is that the stats functions should be wrapped in a module and
then included (extended?) when desired. But despite reading the
tutorials and docs, I'm not sure what's considered the stylistically
correct way (and the syntax) to package that up.

Comments? Pointers?

Thanks!

- ff

[P.S.: Before you tell me about available stats packages, etc, note that
I'm only using statistics as an example. My real question is about
extending a class...]

···

--
Posted via http://www.ruby-forum.com/.

Assume I'd like to create a statistics package designed to work on
Arrays [but see P.S.]. One way to do this would be to create functions
that take an array as an argument:

  def mean(array)
    return NaN unless array && array.size > 0
    array.reduce(0.0) {|accum, val| accum + val} / array.size
  end

... but that's so old school. What I'd really like is to *cleanly*

extend the Array class so you can operate on it directly, as in:
  >> [1, 2, 3].mean

  => 2.0

I'm sure that it's considered bad style to simply open the Array class
and extend it, since that can lead to unexpected user surprises:

  class Array
    def mean
      return NaN unless self.size > 0
      self.reduce(0.0) {|accum, val| accum + val} / self.size
    end
  end

What kind of surprises?

My hunch is that the stats functions should be wrapped in a module and
then included (extended?) when desired. But despite reading the
tutorials and docs, I'm not sure what's considered the stylistically
correct way (and the syntax) to package that up.

Simple enough:

module MyModule
  def mean
    ...
  end
end

Then, you can always do this:

[].extend MyModule

Or this:

class Array
  include MyModule
end

Then, probably, provide a file people can 'require' that'll do the inclusion
for them, maybe even make that the default.

It might also be nice to provide a way to do this on Enumerables, though that
would be less efficient if you know you have an array. For example:

def mean
  size = 0
  count = inject(0){|accum, val| size+=1; accum+val}
  count / size.to_f
end

···

On Monday, July 05, 2010 03:30:44 pm Fearless Fool wrote:

David Masover wrote:

What kind of surprises?

Coming from conventional programming environments, one might be
surprised when a core class suddenly acquires new methods -- e.g.
Rails/ActiveSupport's extensions to String -- so I wanted to make sure I
was packaging such extensions properly.

Simple enough:
[snip]

Perfect -- I see how that works now. Thank you.

Then, probably, provide a file people can 'require' that'll do the
inclusion for them, maybe even make that the default.

... or if I was feeling adventuresome, perhaps an autoload?

It might also be nice to provide a way to do this on Enumerables, though
that would be less efficient if you know you have an array.

Good catch. If I *do* implement a stats package, I'll think about
making it ambidextrous.

Thanks again.

- ff

···

--
Posted via http://www.ruby-forum.com/.

I agree, this is the less dangerous thing to do: just extend the
specific array instances with your functionality. That way, all other
arrays are left intact.

Jesus.

···

On Mon, Jul 5, 2010 at 11:22 PM, David Masover <ninja@slaphack.com> wrote:

On Monday, July 05, 2010 03:30:44 pm Fearless Fool wrote:

Assume I'd like to create a statistics package designed to work on
Arrays [but see P.S.]. One way to do this would be to create functions
that take an array as an argument:

def mean(array)
return NaN unless array && array.size > 0
array.reduce(0.0) {|accum, val| accum + val} / array.size
end

... but that's so old school. What I'd really like is to *cleanly*

extend the Array class so you can operate on it directly, as in:
>> [1, 2, 3].mean

=> 2.0

I'm sure that it's considered bad style to simply open the Array class
and extend it, since that can lead to unexpected user surprises:

class Array
def mean
return NaN unless self.size > 0
self.reduce(0.0) {|accum, val| accum + val} / self.size
end
end

What kind of surprises?

My hunch is that the stats functions should be wrapped in a module and
then included (extended?) when desired. But despite reading the
tutorials and docs, I'm not sure what's considered the stylistically
correct way (and the syntax) to package that up.

Simple enough:

module MyModule
def mean
...
end
end

Then, you can always do this:

[].extend MyModule

David Masover wrote:
> What kind of surprises?

Coming from conventional programming environments, one might be
surprised when a core class suddenly acquires new methods -- e.g.
Rails/ActiveSupport's extensions to String -- so I wanted to make sure I
was packaging such extensions properly.

Libraries like that do tend to isolate the syntactic sugar from the utility
code. I think the idea is that you might do this instead:

module MathStuff
  def mean(array)
    ...
  end
end

And then, in another file:

class Array
  def mean
    MathStuff.mean self
  end
end

This might be overkill, but the idea here is: If you just require
activesupport, you get all the extensions to string. If you require
active_support/inflector, you get all the string manipulation methods, without
ever having to extend a string -- all your strings stay pure.

I actually don't see a problem with extending String, and I don't see what the
conventional argument is. The _only_ potential problem is namespace conflicts
-- if two different libraries define String#pluralize, and it means a
different thing to each library, you've got a problem.

> Then, probably, provide a file people can 'require' that'll do the
> inclusion for them, maybe even make that the default.

... or if I was feeling adventuresome, perhaps an autoload?

That only automatically works if you then extend/include it at some point. So,
for example, it might make sense like this:

autoload :MathStuff, 'whatever'
...
[].extend MathStuff

It would be kind of wasteful here:

autoload :MathStuff, 'whatever'
class Array
  # always loads right now
  include MathStuff
end

And it'd be completely useless otherwise.

···

On Monday, July 05, 2010 06:16:10 pm Fearless Fool wrote: