Re: Borland Patent on delegation of object events to event handlers
Re: Borland Patent on delegation of object events to event handlers
- Subject: Re: Borland Patent on delegation of object events to event handlers
- From: Bill Bumgarner <email@hidden>
- Date: Fri, 1 Jun 2001 10:00:24 -0400
Go here:
http://164.195.100.11/netahtml/srchnum.htm
And search for patent #6,185,728.
--
A casual read-- I'm certainly no lawyer-- indicates that the patent is
both fairly primitive in the mechanisms it describes, but fairly broad
in terms of the range of functionality it might cover. Unfortunate,
that.
In any case, IB/AppKit is way more advanced than the functionality
described in that patent. Basically, they have patented the notion of
being able to say:
MyButton.OnClick:=MyForm.Button1Click.
For all intents and purposes, it is simply a short hand for using
callback functions to allow a developer to easily bind a particular UI
event to a particular method on some random object.
The equivalent in ObjC/AppKit would be to either:
- drag a connection from a GUI object to the target and connect the
action
or
- do something like:
[myButton setTarget: myForm];
[myButton setAction: @selector(button1Clicked:)];
*yawn*
Fortunately, these are not the same thing-- the AppKit form contains two
lines, not one and is not a simple assignment. It is also a boatload
more powerful in that it decouples the concept of "target" from the
notion of "method to invoke". Example; in the AppKit, the First
Responder mechanism is basically default behavior that occurs
automatically whenever the target is nil.
What do you think happens if you did?
MyButton.OnClick:=NULL.
--
Their claim is that it accelerates the development process by allowing
the developer to do:
with MyButton do
color := Red;
OnClick := MyForm.Button1Click;
{ etc. }
end;
Of course, in the AppKit/IB world, the developer would *never* have to
actually write that code unless they were doing something like building
GUI in a completely dynamic manner. If that were the case, it might be
something more like:
[myButton setColor: [userDefaults colorForKey:
@"PreferredButtonColor"]];
[myButton setAction: NSSelectorFromString([userDefaults
stringForKey:@"ConfiguredButtonAction"]];
[myButton setTarget: nil]; // dynamic dispatch
--
Furthermore, the patent lays claim to "direct language support" for
assignment of event handlers to UI objects and the ability to
dynamically modify said handlers at runtime. To quote:
"Recall that when one normally calls a "function" in a conventional
programming environment, the function is called directly. When one
employs a function pointer, on the other hand, the function is called
indirectly through the pointer to (address of) the function. In
accordance with the present invention, instead of having a function
pointer point to a function, a method pointer is employed which points
to a method of an object--that is, a method of a particular instance of
an object. "
So, in other words, they have basically patented a mechanism that comes
for free as a part of good OO design. It is particularly amusing to
note that Apple/NeXT achieved this level of dynamic behavior without
having to modify any of the languages used for AppKit development. The
Java based APIs to the AppKit provide fully dynamic control over event
dispatch via either IB or through programmatic interfaces without
requiring "Direct Language Support".
Actually, I'm not even sure what "Direct Language Support" really
means. It appears that it means that they allow a method to be
effectively added to a class at runtime through simple assignment.
However, that seems ultra-stupid because there are a myriad of obvious
examples of prior art; python, smalltalk, and CLOS immediatley pop into
mind. If I remember correctly, HyperCard allowed one to make
assignments between "objects' that effectively made functionality
available in the target of the assignment.
OOOOhhhhh... I got it now.
Basically, they are allowing a method of ONE object to be assigned to
ANOTHER object such that when that OTHER object invokes the method on
itself, it actually invokes the method of the FIRST object.
Instead of something like:
[myWindow setDelegate: self];
Then having the window do something like:
if ([delegate respondsToSelector: @selector(windowWillClose:)])
[delegate windowWillClose: self];
And having the delegate implement:
- (void) windowWillClose: (NSWindow *) aWindow;
It would be as if Apple/NeXT had implemented it such that you define the
method as above but then you did:
myWindow.windowWillClose = self.windowWillClose
Then, window would do something like...
windowWillClose(self)
...to call the delegated method. However, because the delegated method
is actually a pointer to some OTHER object's implementation of that
method and the implementation carries with it the reference to "self",
the execution of windowWillClose() would actually occur as if you had
done something like [delegate windowWillClose: self].
Wow. What a breakthrough. Borland has patented the ability to make a
body of code even more confusing and unmaintainable than ever before.
If I'm reading this thing correctly -- maybe, maybe not -- I'm not sure
Apple would *want* to claim prior art beyond "Yeah, NeXT did that in
1987 and realized it was really stupid.".
b.bum
On Friday, June 1, 2001, at 08:35 AM, email@hidden
wrote:
Date: Thu, 31 May 2001 15:03:06 -0700
From: Jim Roepcke <email@hidden>
To: Cocoa Dev <email@hidden>,
email@hidden
Subject: Borland Patent on delegation of object events to event handlers
http://www.borland.com/about/press/2001/patent.html
Isn't there prior art in IB related to this?
Jim