Hello --

On Wed, 25 Jul 2001, Avi Bryant wrote:

> On Wed, 25 Jul 2001, Dave Thomas wrote:
>
> > Stephen White <spwhite / chariot.net.au> writes:
> >
> > > It would be nice if there was some way of showing the connection between
> > > "join" and "split", "pack" and "unpack" and other related operations even
> > > though they reside in different classes.
> >
> > I think this is an excellent thought. Logically, if not in actual
> > implementation, it would be fun to think of an orthogonal set of
> > capabilities that you can add to the language. For example, you might
> > logically say
> >
> >     use 'byte_and_bit_access'   // ok - bad name
> >
> > and String and Array would be augmented with unpack and
> > pack.
>
> Smalltalk always did this with categories - you can ask a browser,
> for example, to show you all the methods in a particular category,
> regardless of class.  It's also fairly common to "file-in" and "file-out"
> by category.  In Ruby, of course, it's quite natural to have a file which adds
> methods to several classes, so that
>
> require 'byte_and_bit_access.rb'
>
> would be fine right now, if the standard libraries happened to be
> modularized that way.
>
> RCR: add smalltalk-like categories to Ruby?  This would involve, at the
> least, having every method know which category it belonged to, from which
> you could build searches for all methods in a particular category, etc.

A question, based on ignorance of Smalltalk (and therefore uncertainty
as to what your idea would entail in Ruby):

What is/would be the practical value of having this kind of
categorization?  I'm assuming that Array would still have #pack, and
so on (i.e., you're not [I think] suggesting that the methods that
currently exist start having to be imported explicitly).  So I'm not
sure under what circumstances one would actually need or use this view
of methods.


David

-- 
David Alan Black
home: dblack / candle.superlink.net
work: blackdav / shu.edu
Web:  http://pirate.shu.edu/~blackdav