[lnkForumImage]
TotalShareware - Download Free Software
Confronta i prezzi di migliaia di prodotti.
Asp Forum
 Home | Login | Register | Search 


 

Forums >

comp.lang.ruby

Re: Adding, removing and redefining features at runtime

Austin Ziegler

9/26/2003 4:11:00 PM

On Sat, 27 Sep 2003 00:05:48 +0900, Martin DeMello wrote:
> Gavin Sinclair <gsinclair@soyabean.com.au> wrote:
>> PS. I am launching a project that consolidates popular extensions to
>> the standard classes. Look at project "extensions" on RubyForge if
>> you're interested. The CVS will hopefully be there within 7 days. A
>> release will be a few more weeks. This is inspired by that nagging
>> feeling. Instead of implementing common modifications in my code, I can
>> rely on a reference implementation that is documented and tested.
> Excellent idea. Two questions, though - how do you define popularity, and
> how do you avoid bloat?

I can think of two things that should be there: #map_with_index and number
formatting, since they appear every so often. Other examples exist, I am
sure, but seeing what extensions are listed on the RubyGarden wiki would be
a good start.

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 do you think?

-austin
--
austin ziegler * austin@halostatue.ca * Toronto, ON, Canada
software designer * pragmatic programmer * 2003.09.26
* 12.01.15
4 Answers

Gavin Sinclair

9/26/2003 4:43:00 PM

0

On Saturday, September 27, 2003, 2:10:42 AM, Austin wrote:

> On Sat, 27 Sep 2003 00:05:48 +0900, Martin DeMello wrote:
>> Gavin Sinclair <gsinclair@soyabean.com.au> wrote:
>>> PS. I am launching a project that consolidates popular extensions to
>>> the standard classes. Look at project "extensions" on RubyForge if
>>> you''re interested. The CVS will hopefully be there within 7 days. A
>>> release will be a few more weeks. This is inspired by that nagging
>>> feeling. Instead of implementing common modifications in my code, I can
>>> rely on a reference implementation that is documented and tested.

>> Excellent idea. Two questions, though - how do you define popularity, and
>> how do you avoid bloat?

> I can think of two things that should be there: #map_with_index and number
> formatting, since they appear every so often. Other examples exist, I am
> sure, but seeing what extensions are listed on the RubyGarden wiki would be
> a good start.

#map_with_index is there now. Well, on my computer anyway.

> 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 do you think?

> -austin

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.

However, you are the second person to propose what you did, so I''ll
have to give it some thought.

BTW, the extension package is conservative. If an intended method
already exists, it emits a warning and doesn''t overwrite the
method. Also, an exception is thrown if a method is claimed to be
implemented but isn''t.

Gavin

Hal E. Fulton

9/26/2003 5:19:00 PM

0

Austin Ziegler wrote:
> I can think of two things that should be there: #map_with_index and number
> formatting, since they appear every so often. Other examples exist, I am
> sure, but seeing what extensions are listed on the RubyGarden wiki would be
> a good start.

Some suggestions.

_The Ruby Way_ has some odds and ends that might be useful here. Use
them freely if you wish, but I think a comment saying which ones came
from there would be appropriate. Source is in the RAA.

Also, nil_or_empty? comes up from time to time. I sympathize with the
need for it, but I prefer the name null?. These expressions would all
be true:

nil.null?
[].null?
"".null?
0.null? # I''m uncertain about this one.

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

I like having odd? and/or even? methods for numbers, but that''s just
me.


Cheers,
Hal

Mauricio Fernández

9/26/2003 5:32:00 PM

0

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)
>
> I like having odd? and/or even? methods for numbers, but that''s just
> me.

Florian Gross found one way to do

array.map(&:capitalize)

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

--
_ _
| |__ __ _| |_ ___ _ __ ___ __ _ _ __
| ''_ \ / _` | __/ __| ''_ ` _ \ / _` | ''_ \
| |_) | (_| | |_\__ \ | | | | | (_| | | | |
|_.__/ \__,_|\__|___/_| |_| |_|\__,_|_| |_|
Running Debian GNU/Linux Sid (unstable)
batsman dot geo at yahoo dot com

LOAD "LINUX",8,1
-- Topic on #LinuxGER

Hal E. Fulton

9/26/2003 5:53:00 PM

0

Mauricio Fern&#225;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