Thufir wrote:

> Put another way:  there must be a non-contrived case of composition in
> Ruby?  Yes?

I do not really see this as a contrived example of composition; the only 
thing that I did not like in the solution we examined is the name 
'Engine' for a module (for a principle given by D.Black of 'adjectives 
for Modules, and nouns for Classes'..). But I think that the advantage 
of a Module in this case trounces the naming principle (so far; perhaps 
if design continued..).

For your question about existing examples of 'Composition': is this the 
eternal OO issue about 'to have' vs 'to be', and the need for objects to 
'contain' other objects?

I can only mention the only Ruby application that I looked at: Rails 
(not as an user, but internally, to study how Ruby can be used). In 
Rails definitely we find objects which 'contain' other objects (I will 
however use the name 'reference' from now on, as I detest the word 
'containment'); for example:
- the Dispatcher references the objects request, response, and the 
Controller class name
- the Controller (besides request, response received from the 
Dispatcher) creates an Anonymous Class View and then it instantiates it; 
so it references the instance view (which allows cool tricks for 
instance variables passing).

However, reading Rails, this is NOT what strikes the reader (what is the 
big deal about objects referencing other objects?), but rather the 
explosive combination of INHERITANCE + MIXIN + METAPROGRAMMING to glue 
the system together; for example, what modules ActionController::Helpers 
and ClassMethods do on behalf of the Controller (and View).

Here is where Ruby shows facets that other languages cannot even dream 
of (and I doubt that we should worry about mimicking with Ruby what 
others are doing..); but I am getting off theme.

I hope others will give you more useful examples,
good luck

Raul
-- 
Posted via http://www.ruby-forum.com/.