How to fulfill the "code-reuse" destiny of OOP?

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
29 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Re: How to fulfill the "code-reuse" destiny of OOP?

shelby-3
Magicloud wrote:
> I am not saying that the code has to be in OO style. When I say OO is
> general, I mean I am thinking in OO style. This reflects on modeling,
> program structure, even code organization.
> Style is how we present things. I think that is less important than
> how we think about things.

Style is irrelevant to the larger theorems of the universe which tells us
that OOP must be granular in architecture (composability will force it,
else code has to be re-written), thus I cross link this thread to "Base
classes can be _ELIMINATED_ with interfaces":

http://www.haskell.org/pipermail/haskell-cafe/2009-November/068432.html
_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: How to fulfill the "code-reuse" destiny of OOP?

Peter Verswyvelen-2
In reply to this post by Gregory Collins-3
On Sun, Nov 1, 2009 at 2:57 AM, Gregory Collins <[hidden email]> wrote:
Doing OO-style programming in Haskell is difficult and unnatural, it's
true (although technically speaking it is possible). That said, nobody's
yet to present a convincing argument to me why Java gets a free pass for
lacking closures and typeclasses.

I might be wrong, but doesn't Java's concepts of inner classes and interfaces together with adapter classes can be used to replace closures and typeclasses in a way?

An inner class allows you to implicitly capture the parent object ("environment"), just like a closure does in a sense.

Interfaces group together methods, like type classes do. 

Although I'm actually a C# fanboy for doing "industrial" programming, I think the Java designers did an excellent job, finding a good balance in language features, ease of use and readability, and although C# does offer closures and many more FP constructs, I really miss the above Java constructs.



_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: How to fulfill the "code-reuse" destiny of OOP?

Martin Coxall-2

On 13 Jan 2010, at 09:51, Peter Verswyvelen wrote:

On Sun, Nov 1, 2009 at 2:57 AM, Gregory Collins <[hidden email]> wrote:
Doing OO-style programming in Haskell is difficult and unnatural, it's
true (although technically speaking it is possible). That said, nobody's
yet to present a convincing argument to me why Java gets a free pass for
lacking closures and typeclasses.

I might be wrong, but doesn't Java's concepts of inner classes and interfaces together with adapter classes can be used to replace closures and typeclasses in a way?

Inner classes are not a semantic replacement for closures, even if you discount horrific syntax. Inner classes do not close over their lexical environment.

Martin

_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

RE: How to fulfill the "code-reuse" destiny of OOP?

Sittampalam, Ganesh
In reply to this post by Peter Verswyvelen-2
The problem with interfaces as a replacement for type classes is that they only provide dispatch based on the specific type of the first argument (i.e. the receiver).
 
Type classes allow you to dispatch based on return type, and on the instantiations of generic parameters. Neither of these things is reasonably possible with interfaces.
 
For example you can't directly implement the Read type class with interfaces. Neither can you implement a function of type [a] -> ... where the dispatch is based on the instantiation of a - even if you can add an interface to the [] generic type, you might not have a concrete object of type a to dispatch from if the empty list is passed as an argument.
 


From: [hidden email] [mailto:[hidden email]] On Behalf Of Peter Verswyvelen
Sent: 13 January 2010 09:52
To: Gregory Collins
Cc: [hidden email]
Subject: Re: [Haskell-cafe] How to fulfill the "code-reuse" destiny of OOP?

On Sun, Nov 1, 2009 at 2:57 AM, Gregory Collins <[hidden email]> wrote:
Doing OO-style programming in Haskell is difficult and unnatural, it's
true (although technically speaking it is possible). That said, nobody's
yet to present a convincing argument to me why Java gets a free pass for
lacking closures and typeclasses.

I might be wrong, but doesn't Java's concepts of inner classes and interfaces together with adapter classes can be used to replace closures and typeclasses in a way?

An inner class allows you to implicitly capture the parent object ("environment"), just like a closure does in a sense.

Interfaces group together methods, like type classes do. 

Although I'm actually a C# fanboy for doing "industrial" programming, I think the Java designers did an excellent job, finding a good balance in language features, ease of use and readability, and although C# does offer closures and many more FP constructs, I really miss the above Java constructs.



==============================================================================
Please access the attached hyperlink for an important electronic communications disclaimer:
http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html
==============================================================================



_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: How to fulfill the "code-reuse" destiny of OOP?

Sebastian Fischer

On Jan 13, 2010, at 11:00 AM, Sittampalam, Ganesh wrote:

Type classes allow you to dispatch based on return type, and on the instantiations of generic parameters. Neither of these things is reasonably possible with interfaces.

There is recent work that generalises the capabilities of interfaces in Java:


Seeing type-class features in Java disguise highlights the differences between the two concepts that you mention.

Sebastian


-- 
Underestimating the novelty of the future is a time-honored tradition.
(D.G.)




_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: How to fulfill the "code-reuse" destiny of OOP?

Peter Verswyvelen-2
In reply to this post by Sittampalam, Ganesh
Yes that is true, but often in Haskell I had to use type annotations
when the dispatch is based on the return type, so it also has some
tradeoffs.

Don't get me wrong, I see the advantages of Haskell's type classes and
closures, and I love these. But in Java - if you stay close to OO, and
don't try to do FP - you can accomplish a lot, albeit with a lot of
boilerplate. IMO, it's not because you have less lines of code in
Haskell, that the code becomes more readable per se. I'm not a Java
expert, but I have no troubles at all reading Java code, even though
that code is typically twice as long as similar C# code, and maybe ten
times as long as Haskell or ML code (at least if the side effects are
kept local enough, which is good practice in OO anyway). But after
many years of playing with Haskell, I still fail to read and
understand a lot of Haskell code (maybe because it is written by
people with a much higher IQ than mine I guess)

On Wed, Jan 13, 2010 at 11:00 AM, Sittampalam, Ganesh
<[hidden email]> wrote:

> The problem with interfaces as a replacement for type classes is that they
> only provide dispatch based on the specific type of the first argument (i.e.
> the receiver).
>
> Type classes allow you to dispatch based on return type, and on the
> instantiations of generic parameters. Neither of these things is reasonably
> possible with interfaces.
>
> For example you can't directly implement the Read type class with
> interfaces. Neither can you implement a function of type [a] -> ... where
> the dispatch is based on the instantiation of a - even if you can add an
> interface to the [] generic type, you might not have a concrete object of
> type a to dispatch from if the empty list is passed as an argument.
>
> ________________________________
> From: [hidden email]
> [mailto:[hidden email]] On Behalf Of Peter Verswyvelen
> Sent: 13 January 2010 09:52
> To: Gregory Collins
> Cc: [hidden email]
> Subject: Re: [Haskell-cafe] How to fulfill the "code-reuse" destiny of OOP?
>
> On Sun, Nov 1, 2009 at 2:57 AM, Gregory Collins <[hidden email]>
> wrote:
>>
>> Doing OO-style programming in Haskell is difficult and unnatural, it's
>> true (although technically speaking it is possible). That said, nobody's
>> yet to present a convincing argument to me why Java gets a free pass for
>> lacking closures and typeclasses.
>
> I might be wrong, but doesn't Java's concepts of inner classes and
> interfaces together with adapter classes can be used to replace closures and
> typeclasses in a way?
> An inner class allows you to implicitly capture the parent object
> ("environment"), just like a closure does in a sense.
> Interfaces group together methods, like type classes do.
> Although I'm actually a C# fanboy for doing "industrial" programming, I
> think the Java designers did an excellent job, finding a good balance in
> language features, ease of use and readability, and although C# does offer
> closures and many more FP constructs, I really miss the above Java
> constructs.
>
>
> ==============================================================================
> Please access the attached hyperlink for an important electronic
> communications disclaimer:
> http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html
> ==============================================================================
>
_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: How to fulfill the "code-reuse" destiny of OOP?

Gregory Collins-3
In reply to this post by Peter Verswyvelen-2
Peter Verswyvelen <[hidden email]> writes:

> On Sun, Nov 1, 2009 at 2:57 AM, Gregory Collins <[hidden email]> wrote:
>
>     Doing OO-style programming in Haskell is difficult and unnatural,
>     it's true (although technically speaking it is possible). That
>     said, nobody's yet to present a convincing argument to me why Java
>     gets a free pass for lacking closures and typeclasses.
>
> I might be wrong, but doesn't Java's concepts of inner classes and
> interfaces together with adapter classes can be used to replace
> closures and typeclasses in a way?

Maybe, in the same sense that a lawnmower engine strapped to a
skateboard is a replacement for a car: it takes you ten times as long to
get to your destination and you're cold and wet when you get there.

G
--
Gregory Collins <[hidden email]>
_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: How to fulfill the "code-reuse" destiny of OOP?

Robert Greayer-2
In reply to this post by Martin Coxall-2
On Wed, Jan 13, 2010 at 4:56 AM, Martin Coxall <[hidden email]> wrote:

>
> On 13 Jan 2010, at 09:51, Peter Verswyvelen wrote:
>
> On Sun, Nov 1, 2009 at 2:57 AM, Gregory Collins <[hidden email]>
> wrote:
>>
>> Doing OO-style programming in Haskell is difficult and unnatural, it's
>> true (although technically speaking it is possible). That said, nobody's
>> yet to present a convincing argument to me why Java gets a free pass for
>> lacking closures and typeclasses.
>
> I might be wrong, but doesn't Java's concepts of inner classes and
> interfaces together with adapter classes can be used to replace closures and
> typeclasses in a way?
>
> Inner classes are not a semantic replacement for closures, even if you
> discount horrific syntax. Inner classes do not close over their lexical
> environment.
> Martin

Anonymous classes in Java close over their lexical environment (can
refer to variables in that lexical environment, with values bound at
the time of instance construction) with the caveat that only local
variables/parameters marked as 'final' may be referred to.  Aside from
the horrible syntax, this is the key distinction between them, and,
say, Ruby closures.  Referring to mutable variables from inside a
closure has its drawbacks, making the horrible syntax the biggest
stumbling block to using them IMHO (other than runtime overhead, which
I believe is also an issue).
_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: How to fulfill the "code-reuse" destiny of OOP?

Martin Coxall-2
>>
>
> Anonymous classes in Java close over their lexical environment (can
> refer to variables in that lexical environment, with values bound at
> the time of instance construction) with the caveat that only local
> variables/parameters marked as 'final' may be referred to.  Aside from
> the horrible syntax, this is the key distinction between them, and,
> say, Ruby closures.  Referring to mutable variables from inside a
> closure has its drawbacks, making the horrible syntax the biggest
> stumbling block to using them IMHO (other than runtime overhead, which
> I believe is also an issue).


Yes, this. Which makes them basically unusable where you might want proper closures.
_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
12