Prev: extending a core class cleanly [noobish alert]
Next: Golf on CLI code
From: Fearless Fool on 5 Jul 2010 19:16
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/.

From: David Masover on 6 Jul 2010 20:59
On Monday, July 05, 2010 06:16:10 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.

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.

 | 
Pages: 1
Prev: extending a core class cleanly [noobish alert]
Next: Golf on CLI code