On 24 Apr 2008, at 22:25, Robert Klemme wrote:
> On 24.04.2008 12:15, Eleanor McHugh wrote:
>> On 24 Apr 2008, at 10:40, Martin Vales wrote:
>
>>> I have always had a doubt about OOP.
>>> Usually we have a parent and several child, but what happen if we  
>>> need
>>> the inverse system. for example DBI/DBD APIs.??
>>>
>>> I need build map proyections and i want and intermediate API for all
>>> proyections clases.
>
> What exactly do you mean by "intermediate"?  Do you mean that all  
> projections should have the same interface?  For that you do not  
> need inheritance at all - at least in Ruby.  Or do you rather mean  
> that they share behavior (implementation)?
>
>>> All map proyections have the same methods (geodetic_to_projected and
>>> projected_to_geodetic)
>> Then define either a projection class from which they all inherit,  
>> or  a projection module which they all include.

And if these functions are included from a module their names should  
be to_projected and to_geodetic as it doesn't matter to other classes  
what they're being translated from.

> Nice reading from you again, Ellie. :-)

Damn, I've gone and blown my anonymity again ;)

> I was going to also suggest the module approach.  But I do wonder  
> why Martin chose to call it "inverse OOP".  It seems the more  
> appropriate term would be "multiple inheritance" or am I missing  
> something?

That was my reaction. I did a lot of similar work many years ago when  
I was a VB hacker and abstracted projections using interfaces, which  
are marginally similar to Ruby's modules, but it's possible Martin has  
some more complicated use case in mind.


Ellie

Eleanor McHugh
Games With Brains
http://slides.games-with-brains.net
----
raise ArgumentError unless @reality.responds_to? :reason