Gavin Sinclair
9/26/2003 11:53:00 PM
On Saturday, September 27, 2003, 5:44:32 AM, Austin wrote:
> 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
>>> [...]
>> 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!" ;)
> -austin
Gavin