D. Tweed wrote:
> On Fri, 18 Aug 2000, Doug Ransom wrote:
>
> > I do believe FP is current 90 degrees out of phase with OO. I
think the
> > isue with tuples, lists, conses, etc. it the big problem. I
currently see
> > no way for someone to write a clever matrix library in Haskell
and have it
> > seamlessly integrate into the NGWS framework (the new object type and
> > runtime system from MS likely here to stay for a long long time)
and C#, VB,
> > etc. The impedance mismatch is just too high.
>
> I can't quite see why you say (at least twice) `is 90 degrees out
of phase
> with OO' rather than `90 degrees out of phase with lots of
assumptions &
I think there are two interpretations on what makes up an object
oriented system; the interpretation founded in Simula, and the
interpretation founded in Smalltalk. IIRC, the term object
orientation was coined by Alan Kay, in reference to Smalltalk.
The great difference between object oriented languages with static
method dispatch, like C++, and Java to some extent, and languages
with dynamic method dispatch, such as Smalltalk, Objective-C and TOM,
is vast --- but you have to be experienced in designing for such
languages to notice the difference.
As far as I can see, using a state monad makes it possible to create
a static object oriented language within Haskell. Haskell++ is an
example of this.
However, the gap between Haskell and dynamic object oriented
languages is much greater. The existence of a universal object type
(id or Any) is central to the design paradigm of such languages ---
collections of anonymous objects would be impossible without them.
Another issue is composition, an example of which is delegation:
- (void) forwardInvocation:(NSInvocation*) invocation
{
if ([delegate respondsToSelector:[invocation selector]])
{
[invocation invokeWithTarget:delegate];
}
else
[super forwardInvocation:invocation];
}
forwardInvocation is the method which gets called when an object
gets send a message for a method that it doesn't implement. Here we
can do error handling, in this case we check if our delegate
implements the method, and in that case, we let the delegate handle
the method.
A delegate is normally typed as
id delegate;
which means that it can be an instance of any class, or
id<MyDelegateProtocol> delegate;
which means that it can be any object responding to the methods in
MyDelegateProtocol.
An example of objects using a delegate is a user interface window;
it lets the delegate get final say on actions such as closing,
resizing and so forth.
Another design pattern which becomes difficult without dynamic
dispatch and object references is notification:
[[NSNotificationCenter defaultCenter] addObserver:self
selector:@selector(handleWindowClosed:)
name:NSWindowDidCloseNotification
object:nil];
This pattern lets an object observe, and react to, the actions of
other objects without having to be directly aware of these objects.
Another example is action/target based user interface modelling:
[button setTarget:anObject action:@selector(buttonPressed:)];
Now, when pressed, the button object will invoke the buttonPressed:
method of the object referred to by anObject. Since the action/target
information part of the state of the object, rather than part of the
program, we can trivially load user interfaces from at run time.
Dynamic dispatch also allows us to extend and amend objects without
subclassing, we can just replace one method implementation with
another at run time, as well as add methods to objects. TOM even
allows adding instance variables at run time. Of course these
abilities create new ways to wreck havoc, but it does not really
matter once you have an imperative system.
Features such as these greatly simplify the design of flexible,
loosely coupled and easily maintained systems.
Much as I like Haskell --- I write a lot of Haskell code and am very
pleased with it, for a certain set of problems --- I'd think twice
about writing a word processor in it --- although I'd consider
writing the glyph layout algorithm in it.
Haskell could conceivably replace C++ and similar languages --- it
probably comes down to improving compilers, creating a wealth of
reusable libraries, and providing cook-book solutions.
However, getting Haskell to a point where it can compete with the
ease of design of dynamic object oriented languages is another
matter. O'Haskell's reactive object's get you part of the way, but
nowhere near far enough.
Regards,
John H�rnkvist
--
ToastedMarshmallow, the perfect Cocoa companion
http://www.toastedmarshmallow.com
