Paul,
The functional model means far more than "you call functions a lot". It
means, in particular, that values do not change state. The entire OO model
is based on imperative notion that an object "has state" and that that state
tends to change over time. Anything with a setter-method is imperative and
not functional. By definition, functional objects cannot change state after
they are constructed. In Java terms, the only functional classes would be
those in which every member variable is declared "final" so it can't change
after construction.
In a (pure) functional language you have the guarantee that for any function
called twice with the same parameters, the result will be the same. In
other words, f(x) == y at all times. This is why Java doesn't call its
methods "functions": the latter term implies something much more specific.
>From this you can see that Iterators are by no means functional in the
technical sense, since the next() method returns a different value every
time. And just about everything in Swing is imperative, since almost every
widget has an intrinsic state. A checkbox is an imperative object. This
isn't a problem, it's just an observation that some problems (in this case
user interfaces) do not fit into the functional model.
It's not too difficult to integrate the "big win" feature of the functional
programming model -- first-class functions -- into an imperative or OO
language. Smalltalk and especially Dylan are two that do this very nicely.
While one would expect a lot of things that "really suck", there are many
many ways to do things differently. There is a vast wealth of knowledge on
how to do things functionally... there's a big paradigm shift involved,
since most of the usual conceptions about data structures get thrown out the
window. But in return for inverting your brainwaves, there are many
enormous advantages to sticking within the pure functional model. To pick
one example, an optimizing compiler can do some pretty incredible things
when it has assurances of functional behavior.
My statement about the cumbersome nature of Inner classes is due to the fact
that you need to define a full interface, and then a full class, in order to
pass along a single function. This in turn makes it much more difficult to
reuse functions in different contexts. For example, there's lots of times
where I want to share a callback between a Runnable (so I can use
invokeLater) and a simple Listener on a button. In order to do that my code
snippet must implement both interfaces. And the next time I find some other
place where the same callback could be used in a different context, maybe
the method name is different so I have to write yet more code.
Functionally, the _types_ of the callbacks are all the same, but in Java
it's very cumbersome to pass the callback to all contexts in which it would
be useful, because each context tends to define its own interface.
If you've not used a language with true closures and first-class functions,
you're missing out on a really cool experience.
Cheers,
.T.
On 2/12/03 3:54 AM, [EMAIL PROTECTED] wrote:
> On Mercredi, f�vr 12, 2003, at 05:51 Europe/Paris, Todd Jonker wrote:
>> [ Most OO languages are pretty aggressively imperative. It's damn near
>> impossible to write a useful Java program without using an assignment.
>> ]
>>
>
> On this I don't agree. I do think you can write lots of useful GUI
> things that almost purely functional (e.g. a Swing model class based on
> some predefined storage). It's just rarely seen.
>
> Moreover there are thing that really suck in functional programming:
> how do you want to make, without a state, something like an iterator
> that walks a tree ? And iterators are really close to functional, are
> immensely useful!
>
> As to the cumbersomeness of the inner-class syntax, I think this really
> only true if you respect the coding conventions which, for most of what
> I have seen, have never talked about these hence require five lines for
> a one line inner-class (e.g. a parameter to
> SwingUtilities.invokeLater() parameter).
>
> Paul
--
War is NOT a necessity!
http://UnitedForPeace.org/ http://MoveOn.org/
http://NotInOurName.net/ http://CWG.org/
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
