comparison OOP and FP (and how to put them together) was: Re: need help with haskell 
Author Message
 comparison OOP and FP (and how to put them together) was: Re: need help with haskell

Quote:

>> However, how often does the need for the OO solution come up in
>> practice?  I suspect it is much less often than people (at least in
>> the OO camp) expect.  Obviously, OO features are used a great deal in
>> OO languages, but how many of those uses are appropriate uses of
>> objects and inheritance, as opposed to clumsy workarounds for `missing
>> features'?  For example, it is my understanding that Java lacks any
>> sort of parameterized types, so that if I want to implement a `set of
>> T', for various types T, the best I can do is implement a `set of
>> Object', be careful to just insert objects of type T into it, and,
>> when extracting elements, explicitly downcast them from Object to T.
>> This is certainly object-oriented, but it's mighty clumsy and throws
>> away type safety.

>Take a look at the different OO languages and how intensively
>inheritance is used it often starts from an abstract class and  more and
>more concrete  implementation are provided. So I think there are a lot
>of people out there which use OO-properly.

>In Eiffel this parameterized types are called generic [...]

Well, OK, Eiffel handles parameterized types fine, but I think there
are still other cases where Eiffel programmers use inheritance as a
clumsy workaround for missing features.  Thus it may just be that the
examples in Eiffel are different to the examples in Java.

For example, Eiffel doesn't have a module system, it only has classes.
So Eiffel programmers use classes even for collections of routines with
no associated data, and, from what I understand, they will then use
inheritance just as a way of gaining unqualified access to that bunch
of routines.

--

WWW: < http://www.*-*-*.com/ ~fjh>  |   but source code lives forever"



Mon, 02 Jul 2001 03:00:00 GMT  
 comparison OOP and FP (and how to put them together) was: Re: need help with haskell

Quote:

> For example, Eiffel doesn't have a module system, it only has classes.
> So Eiffel programmers use classes even for collections of routines with
> no associated data, and, from what I understand, they will then use
> inheritance just as a way of gaining unqualified access to that bunch
> of routines.

Initially I thought this was very odd. Its clear to me that you want to
put associated routines together in a module or class. A good example of
this would be trigonometric functions. No data, but they go together.

There are two approaches that can be taken. Create an instance of this
class and use it.

        trig_functions: TRIG_FUNCTIONS is
                once
                        !!Result
                end

        y := trig_functions.sin (x)

or inherit TRIG_FUNCTIONS to gain the facilities of TRIG_FUNCTIONS.

inherit
        TRIG_FUNCTIONS

...
        y := sin (x)

Using sin in the second case is more pleasing, but its easy to get
caught up with inheritance being 'is_a'.  

If there was a new key word, 'utilises' for TRIG_FUNCTIONS it would be
implemented in exactly the same way as inherit. So whats the difference?
The only difference I is the intention, and a comment or naming
convention works fine.

Its a looks like a duck, walks like a duck, quacks like a duck, so it
must be a duck scenario.

--

Nick



Mon, 02 Jul 2001 03:00:00 GMT  
 comparison OOP and FP (and how to put them together) was: Re: need help with haskell

Quote:

> >> However, how often does the need for the OO solution come up in
> >> practice?  I suspect it is much less often than people (at least in
> >> the OO camp) expect.  Obviously, OO features are used a great deal in
> >> OO languages, but how many of those uses are appropriate uses of
> >> objects and inheritance, as opposed to clumsy workarounds for `missing
> >> features'?  >
...
> For example, Eiffel doesn't have a module system, it only has classes.
> So Eiffel programmers use classes even for collections of routines with
> no associated data, and, from what I understand, they will then use
> inheritance just as a way of gaining unqualified access to that bunch
> of routines.

I wholeheartedly agree. It's an interesting question -- what problems
are `solved' by the object-oriented style that are better solved in
other ways?

(1) Using upcasts and downcasts in a class hierarchy where parametric
polymorphism is the superior approach.

(2) Using inheritance where a sum-of-products datatype is more
appropriate (there is an argument about extensibility here, so it's not
all cut and dried).

(3) Using classes to modularize one's code. A purpose-built module
system is better.

(4) Using objects to encapsulate. Often an ADT mechanism is simpler and
better (in ML, the use of modules and signature matching; even better,
the use of existential types in languages which support them).

(5) The use of an abstract class and concrete subclasses implementing a
single method (especially the use of inner classes in Java) where the
provision of first-class functions is what's really needed.

In Java (and other OO languages), "everything is a class". It's not
necessarily the case that everything is best modelled this way. However,
I don't believe that languages like SML and Haskell provide quite enough
(correct me if you think I'm wrong -- or if there are other languages
out there that provide more). The addition of record/variant
polymorphism or true subtyping would help, but there are some problem
domains for which OO languages are still the `best fit', in my opinion.
GUI programming is an obvious example.

- Andrew.



Mon, 02 Jul 2001 03:00:00 GMT  
 comparison OOP and FP (and how to put them together) was: Re: need help with haskell


Quote:

> trig_functions: TRIG_FUNCTIONS is
> once
> !!Result
> end

You can also use an expanded type to avoid the explicit creation :

trig_functions: expanded TRIG_FUNCTIONS;

Regards
Jocelyn



Mon, 02 Jul 2001 03:00:00 GMT  
 comparison OOP and FP (and how to put them together) was: Re: need help with haskell

Quote:
>Well, OK, Eiffel handles parameterized types fine, but I think there
>are still other cases where Eiffel programmers use inheritance as a
>clumsy workaround for missing features.  Thus it may just be that the
>examples in Eiffel are different to the examples in Java.

>For example, Eiffel doesn't have a module system, it only has classes.
>So Eiffel programmers use classes even for collections of routines with
>no associated data, and, from what I understand, they will then use
>inheritance just as a way of gaining unqualified access to that bunch
>of routines.

How do you adapt (redefine) the routines you import/use in other languages ?

Take a module with 2 routines f and g such that f calls g. If g does not
exactly correspond to what you want, you cannot use f either.
In Eiffel, you inherit from your module, redefine g and call f. That's all.
Late binding takes care to call the right g.
So what you describe as a drawback is an advantage IMO.

Regards
Jocelyn



Mon, 02 Jul 2001 03:00:00 GMT  
 comparison OOP and FP (and how to put them together) was: Re: need help with haskell


Quote:
>> How do you adapt (redefine) the routines you import/use in other languages ?

>> Take a module with 2 routines f and g such that f calls g. If g does not
>> exactly correspond to what you want, you cannot use f either.
>> In Eiffel, you inherit from your module, redefine g and call f. That's all.
>> Late binding takes care to call the right g.
>> So what you describe as a drawback is an advantage IMO.

>What would be useful, of course, is to have a standard documentation
>mechanism for the purpose of each inheritance clause. Some inheritance
>clauses would be documented as implementation only. This is important
>for seamlessness, because BON provides an 'implementation only' marker
>on an inheritance relation (well, EiffelCASE does anyway). It is also
>important for tools that analyse the quality of code, because it may
>allow them to flag dubious client dependencies on implementation-only
>inheritance relations.

>Loryn Jenkins

You seem to be implying that:

class X inherit

    W
        export
            {NONE} all
        end

...

does not provide adequate documentation that implementation inheritance is
being used.  Can you elaborate on this?

--
Jim Cochrane



Mon, 02 Jul 2001 03:00:00 GMT  
 comparison OOP and FP (and how to put them together) was: Re: need help with haskell

Quote:
> How do you adapt (redefine) the routines you import/use in other languages ?

> Take a module with 2 routines f and g such that f calls g. If g does not
> exactly correspond to what you want, you cannot use f either.
> In Eiffel, you inherit from your module, redefine g and call f. That's all.
> Late binding takes care to call the right g.
> So what you describe as a drawback is an advantage IMO.

What would be useful, of course, is to have a standard documentation
mechanism for the purpose of each inheritance clause. Some inheritance
clauses would be documented as implementation only. This is important
for seamlessness, because BON provides an 'implementation only' marker
on an inheritance relation (well, EiffelCASE does anyway). It is also
important for tools that analyse the quality of code, because it may
allow them to flag dubious client dependencies on implementation-only
inheritance relations.

Loryn Jenkins



Tue, 03 Jul 2001 03:00:00 GMT  
 comparison OOP and FP (and how to put them together) was: Re: need help with haskell

Quote:

> How do you adapt (redefine) the routines you import/use in other languages ?

> Take a module with 2 routines f and g such that f calls g. If g does not
> exactly correspond to what you want, you cannot use f either.

Easy. You parameterise f on the function g and then instantiate it to g1
or g2 etc. as appropriate.

-- Andrew.



Tue, 03 Jul 2001 03:00:00 GMT  
 comparison OOP and FP (and how to put them together) was: Re: need help with haskell


Quote:

>> How do you adapt (redefine) the routines you import/use in other
languages ?

>> Take a module with 2 routines f and g such that f calls g. If g does not
>> exactly correspond to what you want, you cannot use f either.

>Easy. You parameterise f on the function g and then instantiate it to g1
>or g2 etc. as appropriate.

Easy if you can foresee it. I for one have no crystal ball ;)
Easy if you can modify the original files. This not always possible :-(

Regards
Jocelyn



Tue, 03 Jul 2001 03:00:00 GMT  
 comparison OOP and FP (and how to put them together) was: Re: need help with haskell

Quote:


> >Easy. You parameterise f on the function g and then instantiate it to g1
> >or g2 etc. as appropriate.

> Easy if you can foresee it. I for one have no crystal ball ;)
> Easy if you can modify the original files. This not always possible :-(

If the implementor of the class did not foresee the need for
redefinition of g, than g (and f!) will most probably not be well-suited
for such a redefinition. You are likely to end up relying on fragile
implementation details -- without even knowing.

        - Andreas



Tue, 03 Jul 2001 03:00:00 GMT  
 comparison OOP and FP (and how to put them together) was: Re: need help with haskell

:
:For example, Eiffel doesn't have a module system, it only has classes.
:So Eiffel programmers use classes even for collections of routines with
:no associated data, and, from what I understand, they will then use
:inheritance just as a way of gaining unqualified access to that bunch
:of routines.

What's wrong with that?

--
*        Matthew B. Kennel/Institute for Nonlinear Science, UCSD          
*
*          "do || !do;  try: Command not found"
*                                         /sbin/yoda --help



Wed, 04 Jul 2001 03:00:00 GMT  
 comparison OOP and FP (and how to put them together) was: Re: need help with haskell

Quote:


>:
>:For example, Eiffel doesn't have a module system, it only has classes.
>:So Eiffel programmers use classes even for collections of routines with
>:no associated data, and, from what I understand, they will then use
>:inheritance just as a way of gaining unqualified access to that bunch
>:of routines.

>What's wrong with that?

There's nothing particularly wrong with it.  However, it just goes to
show that people writing in OOP languages often use inheritance in
circumstances where people using other kinds of languages would use
other features.

--

WWW: <http://www.cs.mu.oz.au/~fjh>  |   but source code lives forever"



Thu, 05 Jul 2001 03:00:00 GMT  
 comparison OOP and FP (and how to put them together) was: Re: need help with haskell

Quote:



> >What would be useful, of course, is to have a standard documentation mechanism
> for the purpose of each inheritance clause. Some inheritance
> >clauses would be documented as implementation only. This is important for
> seamlessness, because BON provides an 'implementation only' marker
> >on an inheritance relation (well, EiffelCASE does anyway). It is also important
> for tools that analyse the quality of code, because it may
> >allow them to flag dubious client dependencies on implementation-onlyinheritance
> relations.

> >Loryn Jenkins
> You seem to be implying that:
> class X inherit
>     W
>         export
>             {NONE} all
>         end
> does not provide adequate documentation that implementation inheritance is
> being used.  Can you elaborate on this?

I'd agree with Loryn here - I have often thought it was not entirely clear (e.g. to
less experienced developers, new team members etc) what the intention of each
inheritance was. The intentions: is-a(-kind-of), uses-implementation,
uses-facility, conforms-to-interface, etc all turn up often, and while the more
experienced person will understand export {NONE} all as the/an eiffel idiom for
uses-implementation, the intention is not stated as such.

If a nice way of interweaving comments into inheritance clauses could be found, as
well as agreed upon idioms for all types of inheritance, then the case tool and
bench could be even more in sync, and the code would be that much more expressive
at little extra cost. Of course more serious analysis of the code would require
different keywords or syntax, not just comments.

- thomas beale



Fri, 06 Jul 2001 03:00:00 GMT  
 comparison OOP and FP (and how to put them together) was: Re: need help with haskell

Quote:

>For example, Eiffel doesn't have a module system, it only has classes.

Slight correction: classes *are* Eiffel's module system.

Quote:
>So Eiffel programmers use classes even for collections of routines with
>no associated data, and, from what I understand, they will then use
>inheritance just as a way of gaining unqualified access to that bunch
>of routines.

Do you have a superior solution in mind?  It seems to me that
inheritance, while not originally intended for simple module
composition, succeeds quite well in that regard.  And, as
Jocelyn points out in another post, you get the additional
benefits of inheritance for free.

--
--
Patrick Doyle                      TINCC



Fri, 06 Jul 2001 03:00:00 GMT  
 comparison OOP and FP (and how to put them together) was: Re: need help with haskell


Quote:


>> >Easy. You parameterise f on the function g and then instantiate it to g1
>> >or g2 etc. as appropriate.

>> Easy if you can foresee it. I for one have no crystal ball ;)
>> Easy if you can modify the original files. This not always possible :-(

>If the implementor of the class did not foresee the need for
>redefinition of g, than g (and f!) will most probably not be well-suited
>for such a redefinition. You are likely to end up relying on fragile
>implementation details -- without even knowing.

Design by Contract helps mitigate this in Eiffel.  It's a different
programming culture, where ad hoc redefinition of things actually
works to a large extent.  Following a few simple, localized rules
helps programmers to build structures that can stand up to
piecewise redefinition without becoming fragile.

--
--
Patrick Doyle                      TINCC



Fri, 06 Jul 2001 03:00:00 GMT  
 
 [ 19 post ]  Go to page: [1] [2]

 Relevant Pages 

1. OO and FP [Fwd: comparison OOP and FP (and how to put them together) was: Re: need help with haskell]

2. Need help putting COM puzzle together

3. DBC in functional languages [Was: comparison OOP and FP]

4. FP Component Libraries? (FP vs OOP)

5. Help I am having an Internal error:tpsbt.cpp line 1477

6. Putting systems together

7. putting together a comp.lang.prolog FAQ

8. A new way to put text and bitmaps together in a button

9. Putting together an interface using tcl (along with wish and xf)

10. Need some help using HTML and UINCODE together

11. OOP => FP

12. What language do you think is a good combination between OOP and FP

 

 
Powered by phpBB® Forum Software