Adding, removing and redefining features at runtime

ruby-talk
21

The reason I suggest it is that while there aren’t too many extensions
(yet), there are possibilities for more. In the ruwiki stuff that I did for
version 0.5.0, I made it so that you can add new transformation items in a
subdirectory and they will be loaded appropriately when you load the “main”
item, as I’ve specified.

By allowing more specific granularity (and I’m not suggesting
file-per-method, but rather “logical” grouping), you make it so that people
don’t have to load all of the extensions that are available.

-austin

···

On Sat, 27 Sep 2003 01:43:09 +0900, Gavin Sinclair wrote:

IMO, the way to avoid bloat is like this:
ext.rb # loads everything
ext/numeric
ext/numeric.rb # loads all extensions to Numeric classes
ext/numeric/format.rb
ext/enumerable
ext/enumerable.rb # loads all extensions to Enumerable
ext/enumerable/map.rb

The file ext/numeric/format.rb could contain the number formatting
routine I wrote and is currently on the RubyGarden wiki. If there are
other numeric formatting routines, they could be put there as well. The
file ext/enumerable/map.rb could contain #map_with_index.

What I have chosen is:

require “extensions/all” # everything
require “extensions/enumerable”
require “extensions/io”
require “extensions/string”

Since these deal exclusively with modifications to core classes, it makes
sense to me that the things you load should be named after them. It
doesn’t make sense to me that finer granularity is required, because: (a)
it’s too much to remember and too much hassle to look up; and (b) the
extensions shouldn’t be so numerous as to require it.

–
austin ziegler * austin@halostatue.ca * Toronto, ON, Canada
software designer * pragmatic programmer * 2003.09.26
* 15.39.48

22

Mauricio Fernández wrote:

···

On Sat, Sep 27, 2003 at 02:19:15AM +0900, Hal Fulton wrote:

I like the “mapf” idea someone had (map function). Example:
Instead of
array.map {|x| x.capitalize }
we could do
array.mapf(:capitalize)

Florian Gross found one way to do

array.map(&:capitalize)

(defining Symbol#to_proc), if you can stand the line noise.

I’d probably prefer mapf. But this solution is elegant
and interesting. I didn’t even realize there was a to_proc.

Hal

23

IMO, the way to avoid bloat is like this:
ext.rb # loads everything
ext/numeric
ext/numeric.rb # loads all extensions to Numeric classes
ext/numeric/format.rb
ext/enumerable
ext/enumerable.rb # loads all extensions to Enumerable
ext/enumerable/map.rb
[…]

What I have chosen is:

require “extensions/all” # everything
require “extensions/enumerable”
require “extensions/io”
require “extensions/string”
[…]

The reason I suggest it is that while there aren’t too many extensions
(yet), there are possibilities for more. In the ruwiki stuff that I did for
version 0.5.0, I made it so that you can add new transformation items in a
subdirectory and they will be loaded appropriately when you load the “main”
item, as I’ve specified.

I like plugin concepts as well, but I don’t know how useful it is
here, as the point of the package is to provide a known interface and
implementation, not to allow extra user-defined extensions.

By allowing more specific granularity (and I’m not suggesting
file-per-method, but rather “logical” grouping), you make it so that people
don’t have to load all of the extensions that are available.

That’s fair enough, if someone can think of some logical groupings.
And in the (usual) case where there aren’t enough extensions to
warrant a grouping, it can degenerate. Thus

require ‘extensions/enumerable/mwi’
require ‘extensions/string’

I still believe YAGNI, so it’s something that will evolve as needed.

Personally, I would always require ‘extensions/all’ because I don’t
care about startup costs (within reason) and would be on the lookout
for collisions. Besides, all the methods are supposed to be a ntural
fit within Ruby, and I never think “Hey! I’m getting all this Process
functionality I never asked for!” :wink:

-austin

Gavin

···

On Saturday, September 27, 2003, 5:44:32 AM, Austin wrote:

On Sat, 27 Sep 2003 01:43:09 +0900, Gavin Sinclair wrote: