OOP => FP 
Author Message
 OOP => FP

Hello,

what is a way of going from an OOP-Style
to an FP-Style?

When using objects, one encapsulates data
via methods.
How is such combination done in an FPL?
Is it a tuple of data-lists and its functions/methods?

TIA,
  Oliver
--
 The direct combination of functions by means of the operator '.' which we
 have seen here is not possible in other programming paradigms, or at least
 it would be an 'advanced' aspect of the language, rather than appearing on
 page 11 of an introductory text.       (Simon Thompson)



Tue, 23 Sep 2003 23:43:23 GMT  
 OOP => FP
Hello,
I can only speak for Haskell. There you encapsulate data by putting data
types and functions into a module and exporting only the things users of the
module shall see. With types you can export all, some or no data constructors
so that you can for instance hide the whole type implementaton and grant
access to it only via functions of the module.
Haskell has also a class construct but it should not be confused with the
class concept found in OOP. A Haskell class is somewhat similar to an
interface in Java, Visual Basic, COM etc.

Wolfgang

Quote:

> Hello,

> what is a way of going from an OOP-Style
> to an FP-Style?

> When using objects, one encapsulates data
> via methods.
> How is such combination done in an FPL?
> Is it a tuple of data-lists and its functions/methods?

> TIA,
>   Oliver



Wed, 24 Sep 2003 01:47:07 GMT  
 OOP => FP

OB> what is a way of going from an OOP-Style
OB> to an FP-Style?

  OO model works well with FP. Just don't use mutable
objects, and you'll got Objective FP.

--

   V.S.Lugovsky aka Mauhuur (http://ontil.ihep.su/~vsl) (UIN=45482254)



Wed, 24 Sep 2003 23:54:12 GMT  
 OOP => FP

Quote:

> what is a way of going from an OOP-Style
> to an FP-Style?

I don't know whether you mean writing OO-style programs in functional
languages, or changing your coding style into a functional one. As for
the latter, all I can say is that you should study other people's
functional programs... some standard stylistic differences (which do
affect ease of maintenance) are use of variants instead of alternative
implementations of interfaces, grouping code by operation instead of
the type it works on, pattern matching instead of virtual binding.

If you really are able to program in OO-style, congratulations, not
many people are able to do that.

Quote:
> When using objects, one encapsulates data
> via methods.
> How is such combination done in an FPL?
> Is it a tuple of data-lists and its functions/methods?

A module is the standard solution of functional languages to provide
non-behavior-oriented encapsulated data types. In a module, you define
unencapsulated data types and functions to operate on those, and then
restrict the interface by using a signature (essentially a type
declaration of the services you want to export to the world outside.)

If you are interested in "real" OO, i.e. not just encapsulation but
also behaviour-oriented types, you're in for much work. Ocaml has
facilities for these built-in, but the syntax is not too neat (prettier
than C++ or Java, however, in my opinion). Basically, here's how to do
it without language support:

1. Define a "behaviour" type (record of different functions
   corresponding to methods).
2. Define an abstract  type as a record of the behaviour type and a
   polymorphic variant of the innards (so that different implementations
   may have their own innards).
3. Define a constructor for every alternative type: these are functions
   that can initialise the abstract type with correct behaviour and
   consistent innards.
4. Define abstract toplevel functions for every method. These functions
   should just look at the behaviour record to invoke the correct
   function.
5. Define data structures and functions operating on them for every type
   that implements the interface made above.
6. Wrap everything above as a module and only export constructors and
   the abstract functions.

Panu



Fri, 26 Sep 2003 19:20:17 GMT  
 OOP => FP
Hi Vitaly, et al.

Quote:


> OB> what is a way of going from an OOP-Style
> OB> to an FP-Style?

>   OO model works well with FP. Just don't use mutable
> objects, and you'll got Objective FP.

Then, what's the point? AFAIK all the OO is about simulating objects,
which change state, but retain identity.

Alexander



Sat, 27 Sep 2003 01:12:09 GMT  
 OOP => FP


|> what is a way of going from an OOP-Style
|> to an FP-Style?

Why should you want to? If you want to program in an OO style, use and OO
language, if you want to program in an FP style use an FP language.
It's a bit like asking if there is any way you can use a screwdriver
to hammer in nails.

/Mike



Sat, 27 Sep 2003 01:25:56 GMT  
 OOP => FP

Quote:



> |> what is a way of going from an OOP-Style
> |> to an FP-Style?
> Why should you want to? If you want to program in an OO style, use and OO
> language, if you want to program in an FP style use an FP language.
> It's a bit like asking if there is any way you can use a screwdriver
> to hammer in nails.

Well at least one language provides all programming paradigms,
but it has an own newsgroup. ;-)

But well, what I meant was, how to realize programs in an FPL,
which are (more-or-less;-)) well undestood as by object-oriented
analysis.

I'm recently deepen my OO-knowledge and reading an interesting
book from the beginning of the ninentees.
They argue: It doesn't matter which language you choose; we
think about the design...

...and maybe it doesn't matter, which programming paradigm one uses,
when the resulting software is good (reliable and the solution
matches the necessary points).

But I have thought about realising a problem of my current project.
One of the parts is: parsing a file, create from the given
information html-layout and sql-files.
After thinking about the problem, I had two ideas, how to realize
this program (it's a code-generator): I can do it with lists, or
I can do it with objects.
The objects representing the html-objects (tags for buttons and such),
so objects are a good match to the problem.
But when thinking about tha layout-algorithm I came back to the
lists.
And as more as I thought about it, I think, that the objects are only
a transient representation of the problem.
But maybe they can hold a lot of informations for later enhancements
of the project.

So I'm I came to the point to thjinking about this...

...but on the other side, when the perspective of objects
and the perspective in a functional model are only partial
views of the "reality", because they represent only one
view of it, then the question can not be: OO or FP;
it can only be: OO *AND* FP.
And even all other paradigms, which exists or maybe will
invented one day.

Ciao,
   Oliver

--
 The direct combination of functions by means of the operator '.' which we
 have seen here is not possible in other programming paradigms, or at least
 it would be an 'advanced' aspect of the language, rather than appearing on
 page 11 of an introductory text.       (Simon Thompson, "Haskell")



Sat, 27 Sep 2003 05:19:50 GMT  
 OOP => FP

Quote:

> Well at least one language provides all programming paradigms, but it
> has an own newsgroup. ;-)

If you mean OCaml, it is also discussed in this group.

Quote:
> But well, what I meant was, how to realize programs in an FPL, which
> are (more-or-less;-)) well undestood as by object-oriented analysis.

What do you mean with "well understood"? Probably not object-oriented
analysis of programs? In fact, analyzing functional programs is
significantly easier both for humans and for machines because of the
well-defined semantics of FPLs.

Quote:
> I'm recently deepen my OO-knowledge and reading an interesting book
> from the beginning of the ninentees.  They argue: It doesn't matter
> which language you choose; we think about the design...

The author probably meant "It doesn't matter what OO-language you choose",
because he didn't know about FPLs.  Why don't you read more about the
latter? Ok, there are fewer books, but there are enough to show you
an alternative.

Quote:
> ...and maybe it doesn't matter, which programming paradigm one uses,
> when the resulting software is good (reliable and the solution matches
> the necessary points).

Sure, if the resulting software is good it doesn't matter what language
you used. The question is rather whether the choice of language matters
if you want to write reliable software.

Quote:
> After thinking about the problem, I had two ideas, how to realize
> this program (it's a code-generator): I can do it with lists, or
> I can do it with objects.

You obviously have the very wrong assumption that functional programming
is only about using lists. Lists are a very useful datastructure, but they
are only one of infinitely many. Objects, OTOH, are not a datastructure
as such, they are a way to implement them. The concept behind lists in
functional languages is called algebraic datatypes.

Quote:
> The objects representing the html-objects (tags for buttons and such),
> so objects are a good match to the problem.
> But when thinking about tha layout-algorithm I came back to the
> lists.
> And as more as I thought about it, I think, that the objects are only
> a transient representation of the problem.
> But maybe they can hold a lot of informations for later enhancements
> of the project.

What you need is the typical design of a compiler:

  program          =>  scanner            ->
  token stream     =>  parser             ->
  AST of program   =>  semantic analysis  ->
  AST of output    =>  code generator     ->
  resulting code

You can design the scanner and parser easily with compiler tools like
lex and yacc (e.g. ocamllex and ocamlyacc). Abstract syntax trees are
usually best represented using algebraic datatypes.

The important step is (as usual) the semantic analysis: how can you
get from an AST (abstract syntax tree) that represents the input on a
most abstract level (abstracting from concrete syntax) to an AST that
represents the output?

Since this is obviously a mapping (function):

  semantic_analysis : input_ast -> output_ast

it is obvious that a functional language is extremely suitable for this
task. You will usually use pattern matching to recognize the specific
form of the input AST and map it to the output.

Quote:
> ...but on the other side, when the perspective of objects and the
> perspective in a functional model are only partial views of the
> "reality", because they represent only one view of it, then the question
> can not be: OO or FP; it can only be: OO *AND* FP.

I wouldn't use OO here, but if you cannot resist, try it. I have also
made this mistake. Once.

Regards,
Markus Mottl

--



Sat, 27 Sep 2003 17:46:29 GMT  
 OOP => FP

  -> But well, what I meant was, how to realize programs in an FPL,
  -> which are (more-or-less;-)) well undestood as by object-oriented
  -> analysis.

  -> I'm recently deepen my OO-knowledge and reading an interesting
  -> book from the beginning of the ninentees.  They argue: It doesn't
  -> matter which language you choose; we think about the design...

Problems tend to arise when the OOA work gets into implementation
territory. In most OOA tools I've seen, there is no distinct boundary
between analysis and design (probably because this boundary depends
on your target implementation language.)

When developing Erlang software, we certainly find it useful to
apply OOA to some problems, but you have to know where to stop
doing abstract OOA and start applying the abstractions specific to
your environment.

I've seen far too much of "mindless" OOA/OOD, where it's just taken
for granted that the design will magically translate to a good
implementation regardless of programming language - often with
terrible results, which is discovered late in the project (after all,
it was done the Right Way(tm), so there wasn't any need to verify
characteristics early).

/Uffe
--
Ulf Wiger                                    tfn: +46  8 719 81 95
Senior System Architect                      mob: +46 70 519 81 95
Strategic Product & System Management    ATM Multiservice Networks
Data Backbone & Optical Services Division      Ericsson Telecom AB



Sat, 27 Sep 2003 19:31:02 GMT  
 OOP => FP


Quote:

>Hello,

>what is a way of going from an OOP-Style
>to an FP-Style?

>When using objects, one encapsulates data
>via methods.
>How is such combination done in an FPL?
>Is it a tuple of data-lists and its functions/methods?

Mercury provides typeclasses and existentially quantified types which
can be used to support (many aspects of) OO style programming.

Typeclasses are more like Java/C# interfaces in that a type that
belongs to a typeclass only promises to implement methods (i.e.
functions) of the same signature of that typeclass: there is no
implementation inheritance (although we hope to allow for the
specification of default implementations a la Haskell one of these
days).  This is a Good Thing because you have neither the constraints
of single (implementation) inheritance or the nightmare problems of
multiple inheritance.  Typeclasses can, of course, form an hierarchy.

Be warned: using them in practice is not as straightforward as you
might think (the system also needs class constructors and
functional type dependencies to be really useful; GHC has these, I
believe.)

Existential types provide a way of hiding the `subclass' of an
object.  A function that returns an existentially quantified
result (with typeclass constraint) only guarantees that what you
get back will implement the given typeclass methods.

But there's no getting away from the fact the Mercury is pure and
hence your object methods can't have side effects - any method that
"changes" an object has to, in fact, return a new, updated copy of
that object.  New optimizations being worked on *may* allow the
compiler to spot that destructive update is possible, however.

- Ralph
--



Sat, 27 Sep 2003 19:54:31 GMT  
 OOP => FP


Quote:
>I've seen far too much of "mindless" OOA/OOD, where it's just taken
>for granted that the design will magically translate to a good
>implementation regardless of programming language - often with
>terrible results, which is discovered late in the project (after all,
>it was done the Right Way(tm), so there wasn't any need to verify
>characteristics early).

Seconded.  Indeed, all the commercial C++ programmers I know say they
eschew classes in favour of templates (viz poor man's polymorphism).

- Ralph
--



Sat, 27 Sep 2003 19:58:42 GMT  
 OOP => FP

Quote:


> > Well at least one language provides all programming paradigms, but it
> > has an own newsgroup. ;-)

> If you mean OCaml, it is also discussed in this group.

I guess he means (Common) Lisp, or Dylan. If so, I'd say that CL doesn't
really support all programming paradigms (logic/constraint programming?
concurrent programming?) but it is easier to build new languages in Lisp
than in most other languages.

It's also true that some chunk of OOers don't consider the generic function
approach "truly OO", whatever that means. I admit that I still like the
Lisp family (yes that means Scheme too :) even though I'm decidedly in the
static typing camp.

Quote:
> > But well, what I meant was, how to realize programs in an FPL, which
> > are (more-or-less;-)) well undestood as by object-oriented analysis.

I think when people look back hundred years from now they'll be amazed at
all of this OO crap. Sure, there are some useful tricks you can play, but
does it deserve all of this airtime?

Quote:
> > The objects representing the html-objects (tags for buttons and such),
> > so objects are a good match to the problem.
> > But when thinking about tha layout-algorithm I came back to the
> > lists.
> > And as more as I thought about it, I think, that the objects are only
> > a transient representation of the problem.
> > But maybe they can hold a lot of informations for later enhancements
> > of the project.

> What you need is the typical design of a compiler:

>   program          =>  scanner            ->
>   token stream     =>  parser             ->
>   AST of program   =>  semantic analysis  ->
>   AST of output    =>  code generator     ->
>   resulting code

> You can design the scanner and parser easily with compiler tools like
> lex and yacc (e.g. ocamllex and ocamlyacc). Abstract syntax trees are
> usually best represented using algebraic datatypes.

Our favorite compiler does use some classes in the codegen :-)

Anyways,

Quote:
> > ...but on the other side, when the perspective of objects and the
> > perspective in a functional model are only partial views of the
> > "reality", because they represent only one view of it, then the question
> > can not be: OO or FP; it can only be: OO *AND* FP.

> I wouldn't use OO here, but if you cannot resist, try it. I have also
> made this mistake. Once.

This is very good advice. I think you want to be very careful when using
classes, even in a very good class system like OCaml's. I hate absolute
rules, but if you're beginning OCaml just don't use the object system at
all. Wait until you've mastered core ML *and* the module system.

-- Brian



Sat, 27 Sep 2003 23:36:33 GMT  
 OOP => FP

Quote:


>   -> But well, what I meant was, how to realize programs in an FPL,
>   -> which are (more-or-less;-)) well undestood as by object-oriented
>   -> analysis.
>   -> I'm recently deepen my OO-knowledge and reading an interesting
>   -> book from the beginning of the ninentees.  They argue: It doesn't
>   -> matter which language you choose; we think about the design...
> Problems tend to arise when the OOA work gets into implementation
> territory. In most OOA tools I've seen, there is no distinct boundary
> between analysis and design (probably because this boundary depends
> on your target implementation language.)
> When developing Erlang software, we certainly find it useful to
> apply OOA to some problems,

Yes, that's what I meant.

The analysis of the problem in an OO-way can be clearing mind.

Quote:
> but you have to know where to stop
> doing abstract OOA and start applying the abstractions specific to
> your environment.

Yes, really.

Quote:
> I've seen far too much of "mindless" OOA/OOD, where it's just taken
> for granted that the design will magically translate to a good
> implementation regardless of programming language - often with
> terrible results,

I've seen that too.
And that's a reason, why I hated OO for a long time.
and when one says OOP or Java or such keywords, I
often get angry....
I don't want to use it as a dogmatism; but I also
want not to use FP-Analysis as a dogmatism.

I'm looking for nice ways to analyze problems and to
implement good solutions, which will create pleasure
on the side of the programmer and on the user-side too.

When I talk on OO in this newsgroup i often get sarcastic
comments.
When I then say sarcastic things about FPLs (but OO too),
then that's a problem?

Ciao,
   Oliver
--
 The direct combination of functions by means of the operator '.' which we
 have seen here is not possible in other programming paradigms, or at least
 it would be an 'advanced' aspect of the language, rather than appearing on
 page 11 of an introductory text.       (Simon Thompson, "Haskell")



Sun, 28 Sep 2003 03:26:38 GMT  
 OOP => FP

Quote:

> Our favorite compiler does use some classes in the codegen :-)

Right, but in a very confined context only. I don't think that this
was the only design choice. Xavier wrote about it in some talk slides,
but I am a bit sceptical that there was no way to do it cleanly and
elegantly with the module system alone. Maybe it was an act of kneeling
down before the OO-community so as not to make them look overly stupid
and give them a chance to learn module systems... ;)

(Please forgive me, Wednesday is my evil day! ;)

Regards,
Markus Mottl

--



Sun, 28 Sep 2003 06:40:06 GMT  
 OOP => FP

  -> I've seen that too.  And that's a reason, why I hated OO for a
  -> long time.  and when one says OOP or Java or such keywords, I
  -> often get angry....  I don't want to use it as a dogmatism; but I
  -> also want not to use FP-Analysis as a dogmatism.

OK, here's briefly how I approach it:

You have some very nice behaviours in Erlang/OTP, which are easy
to handle in an OOA context:

- client-server behaviour
- finite state machine
- supervisor
- event manager
- application

These behaviours are formalizations of design patterns.

Apart from that, you can often realize an active object as an Erlang
process.

More lightweight objects can be implemented using the module system:

%% a FIFO queue
-module(queue).
-export([new/0, in/2, out/1]).

new() -> {In = [], Out = []}.

in(Item, {In, Out}) ->
   NewQueue = {[Item|In], Out}.

out({In, [Item|Out]} ->
   NewQueue = {In, Out},
   {Item, NewQueue};
out({In, []}) when In /= [] ->
   out({[], lists:reverse(In)}).

Useage:

Queue0 = queue:new(),
Queue1 = queue:in(17, Queue).
{Item, Queue2} = queue(out, Queue1).

etc.

You can handle inheritance, but should do it explicitly:

-module(typedqueue).
-export([new/1, in/2, out/1]).

new(fifo) ->
  {queue, queue:new()};
new(lifo) ->
  {lifo_queue, lifo_queue:new()}.

in(Item, {queue = Type, Queue}) ->
   {Type, queue:in(Item, Queue)};
in(Item, {lifo_queue = Type, Queue}) ->
   {Type, lifo_queue:in(Item, Queue)}.

etc.

You can of course also use the type specifier above to make the
call directly:

in(Item, {Type, Queue}) ->
   {Type, Type:in(Item, Queue)}.

but I try to be conservative with that as it makes it more
difficult to follow the thread of the program statically.

/Uffe
--
Ulf Wiger                                    tfn: +46  8 719 81 95
Senior System Architect                      mob: +46 70 519 81 95
Strategic Product & System Management    ATM Multiservice Networks
Data Backbone & Optical Services Division      Ericsson Telecom AB



Sun, 28 Sep 2003 17:15:49 GMT  
 
 [ 21 post ]  Go to page: [1] [2]

 Relevant Pages 

1. FP Component Libraries? (FP vs OOP)

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

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

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

5. "FP+OOP=Haskell"

6. "FP+OOP=Haskell" paper

7. etc. FP + OOP

8. Objects with state, or FP + OOP = Haskell++

9. "FP + OOP = Haskell"

10. FP and OOP

11. Abstract data types: FP and OOP?

12. Subclassing vs Subtyping (partly OOP vs FP)

 

 
Powered by phpBB® Forum Software