[lnkForumImage]
TotalShareware - Download Free Software

Confronta i prezzi di migliaia di prodotti.
Asp Forum
 Home | Login | Register | Search 


 

Forums >

comp.lang.ruby

separating specification from implementation

fabrulous@yahoo.fr

6/7/2006 11:15:00 PM

Hi all Rubyers,

I'm considering trying out Ruby. I've got a very specific question: is
it possible to define an abstract data type without tying it to any
implementation?

Note that I'm not debating on the merits of doing that, I'm simply
asking if it's possible in Ruby.

This is doable in Objective-C, in C++, in Java and in C#, for example
(this is definitely *not* the way 99% of Java/C++/C# programmers code
though).

Many programmers consider that OO implies concrete/implementation
inheritance, others (a minority) don't. Once again I'm not debating
the merits of doing that, I just want to know what are the options to
model OO hierarchies in Ruby and if it's possible to model entire OO
hierarchies without being tied to any implementation.

In Java this is possible by only defining ADTs using interface and
"interface inheritance" to model OO hierarchies, in C++ this is
possible by only defining ADTs using "pure abstract classes" (something
Stroustrup has been advocating since 1987 or so, see my .sig), etc.

If it's possible to model an abstract data type in Ruby without being
tied to any implementation detail, how is "code re-use"/"behavior
inheritance" (though I don't like that term very much) done? (in Java
it can be done using delegation, in Objective-C using class cluster,
etc.)

What about multiple inheritance ? (For example in Java it's possible
to define an OO hierarchy in a purely abstract way by two different
methods: using only interface and interface inheritance or using only
pure abstract class [ie abstract class not carrying any method nor any
state]... But in that later case you can say goodbye to multiple
inheritance).

Once again, I'm not asking for something very common nor very
entrenched in people's mentalities, but I just want to know if it's
doable.

Thanks in advance for any infos on this,

fab


--
"Since then (1987) I have consistently pointed out that one of the
major ways of writing classes in C++ is without any state, that is,
just an interface."

Bjarne Stroustrup (on "Modern C++ Style")

7 Answers

Robert Klemme

6/8/2006 6:51:00 AM

0

fabrulous@yahoo.fr wrote:
> Hi all Rubyers,
>
> I'm considering trying out Ruby. I've got a very specific question: is
> it possible to define an abstract data type without tying it to any
> implementation?
>
> Note that I'm not debating on the merits of doing that, I'm simply
> asking if it's possible in Ruby.
>
> This is doable in Objective-C, in C++, in Java and in C#, for example
> (this is definitely *not* the way 99% of Java/C++/C# programmers code
> though).
>
> Many programmers consider that OO implies concrete/implementation
> inheritance, others (a minority) don't. Once again I'm not debating
> the merits of doing that, I just want to know what are the options to
> model OO hierarchies in Ruby and if it's possible to model entire OO
> hierarchies without being tied to any implementation.

No. The reason being that there are no interface contracts and no
interface types at all. You could create a class hierarchy without any
methods but there's no point in doing it IMHO. You probably could
create a set of tests and determine that all objects that pass them
"implement" this ADT.

> In Java this is possible by only defining ADTs using interface and
> "interface inheritance" to model OO hierarchies, in C++ this is
> possible by only defining ADTs using "pure abstract classes" (something
> Stroustrup has been advocating since 1987 or so, see my .sig), etc.
>
> If it's possible to model an abstract data type in Ruby without being
> tied to any implementation detail, how is "code re-use"/"behavior
> inheritance" (though I don't like that term very much) done? (in Java
> it can be done using delegation, in Objective-C using class cluster,
> etc.)

You can implement generic parts of your ADT in a module and have
whatever class wants to implement the ADT include (inherit) that module.

> What about multiple inheritance ? (For example in Java it's possible
> to define an OO hierarchy in a purely abstract way by two different
> methods: using only interface and interface inheritance or using only
> pure abstract class [ie abstract class not carrying any method nor any
> state]... But in that later case you can say goodbye to multiple
> inheritance).

MI can be done with modules much the same as with Java's interfaces -
only that modules can contain real code.

There are numerous tools that try to cover certain aspects of this like
DBC, static typing etc. but it's all retrofitted and not part of the
core language.

Cheers

robert

fabrulous@yahoo.fr

6/8/2006 10:53:00 AM

0

Robert Klemme wrote:
....
> No. The reason being that there are no interface contracts and no
> interface types at all.

OK, so there are no Java-like interface types at all...


> You could create a class hierarchy without any
> methods but there's no point in doing it IMHO.

indeed.


> There are numerous tools that try to cover certain aspects of this like
> DBC, static typing etc. but it's all retrofitted and not part of the
> core language.

oh that's interesting.

Anyway, I'll try it and see if I like it :)

Cheers,

Fab

Edward Garson

6/8/2006 1:03:00 PM

0

What's important to realize about Ruby is that there is no need for
interfaces or abstract types because method calls are resolved by name
at runtime and method arguments are untyped. Interfaces are a means of
achieving polymorphism across heterogenous classes that have the
advantage over abstract base classes that there is no requirement to
derive from a given base class (yes, they also represent contracts etc
but that's a digression in this context IMHO). For this reason I vastly
prefer using interfaces to abstract base classes in statically typed
languages but I digress.

Ruby is a dynamic language whereby a method call is resolved at runtime
by name (although to be sure this is not all that is meant by 'dynamic
language'). Method arguments are untyped, so a call on an object within
a method is resolved at that point. The method can therefore receive
heterogenous objects without the need to use abstract base classes or
interfaces i.e. define the system in these more restrictive terms.
Furthermore, Ruby makes it easy to dynamically add methods at runtime
to classes and objects making for an extremely flexible object system,
but this is not what you were after.

> What about multiple inheritance ?

Ruby implements a flexible but safe means of achieving largely the same
goals as those gained by using multiple inheritance using what are
known as modules. Modules are chunks of reusable code dynamically mixed
into classes and provide namespace semantics to ameliorate the problems
associated with C++ style multiple inheritance.

> how is "code re-use"/"behavior inheritance" [...] done?

See above ;-)

HTH


fabrulous@yahoo.fr wrote:
> Robert Klemme wrote:
> ...
> > No. The reason being that there are no interface contracts and no
> > interface types at all.
>
> OK, so there are no Java-like interface types at all...
>
>
> > You could create a class hierarchy without any
> > methods but there's no point in doing it IMHO.
>
> indeed.
>
>
> > There are numerous tools that try to cover certain aspects of this like
> > DBC, static typing etc. but it's all retrofitted and not part of the
> > core language.
>
> oh that's interesting.
>
> Anyway, I'll try it and see if I like it :)
>
> Cheers,
>
> Fab

Just Another Victim of the Ambient Morality

6/10/2006 5:04:00 AM

0


"Edward Garson" <egarson@gmail.com> wrote in message
news:1149771755.809180.113220@g10g2000cwb.googlegroups.com...
>
>> What about multiple inheritance ?
>
> Ruby implements a flexible but safe means of achieving largely the same
> goals as those gained by using multiple inheritance using what are
> known as modules. Modules are chunks of reusable code dynamically mixed
> into classes and provide namespace semantics to ameliorate the problems
> associated with C++ style multiple inheritance.

In my opinion, the main goal of multiple inheritence is to inherit the
interface of the base classes, rather than their implementation. In this
case, it is still not an issue for Ruby, since everything is duck typed and
all...


Robert Klemme

6/10/2006 12:57:00 PM

0

Just Another Victim of the Ambient Morality <ihatespam@rogers.com>
wrote:
> "Edward Garson" <egarson@gmail.com> wrote in message
> news:1149771755.809180.113220@g10g2000cwb.googlegroups.com...
>>
>>> What about multiple inheritance ?
>>
>> Ruby implements a flexible but safe means of achieving largely the
>> same goals as those gained by using multiple inheritance using what
>> are known as modules. Modules are chunks of reusable code
>> dynamically mixed into classes and provide namespace semantics to
>> ameliorate the problems associated with C++ style multiple
>> inheritance.
>
> In my opinion, the main goal of multiple inheritence is to inherit
> the interface of the base classes, rather than their implementation. In
> this case, it is still not an issue for Ruby, since everything is
> duck typed and all...

Opinions on this differ. I'd be glad from time to time to be able to
inherit method implementations from several sources in Java. An Bertrand
Meyer is also a big fan of implementation inheritance (I probably made that
remark already).

Kind regards

robert

Edward Garson

6/11/2006 1:34:00 PM

0

Hi Robert

> Opinions on this differ. I'd be glad from time to time to be able to
> inherit method implementations from several sources in Java. An Bertrand
> Meyer is also a big fan of implementation inheritance

Do you also feel that it is possible to achieve polymorphism through
delegation, which is often preferable to implementation inheritance?

Kind regards

Edward

Robert Klemme

6/12/2006 12:20:00 PM

0

Edward Garson wrote:
> Hi Robert
>
>> Opinions on this differ. I'd be glad from time to time to be able to
>> inherit method implementations from several sources in Java. An Bertrand
>> Meyer is also a big fan of implementation inheritance
>
> Do you also feel that it is possible to achieve polymorphism through
> delegation, which is often preferable to implementation inheritance?

It's often possible to do that, yes. But both approaches are not
equivalent - especially if object identity comes into play delegation
does not work as good as MI (if it works at all).

Kind regards

robert