Potential patent issues

[Steven Schveighoffer]

On Fri, 21 Jan 2011 15:06:37 -0500, spir <denis.spir at gmail.com> wrote:

> On 01/21/2011 03:51 PM, Don wrote:
>> Don wrote:
>>> BlazingWhitester wrote:
>>>> I spotted some patents that can theaten current DMD implementation.
>>>> Wanted to clarify things.
>>>>
>>>> http://www.freepatentsonline.com/6185728.pdf - this patent describes
>>>> method pointers implementation (delegates)
>>>
>>> This was obviously a patent aimed at protecting Delphi from VB. It's
>>> all about the RAD designer: visual connections between GUI elements
>>> and events has a 1:1 correspondence with code; delegates are used to
>>> achieve this.
>>>
>>> D delegates can store a data pointer to a nested function, or to an
>>> object. This is rather more general (not an object-oriented feature),
>>> and doesn't provide a 1:1 correspondence to visuals.
>>> I presume they were only able to satisfy the requirements for novelty
>>> and non-obviousness, because of the RAD usage. In fact, there doesn't
>>> seem to be any suggestion that delegates would be used for anything  
>>> else.
>>> The more general idea of storing a data pointer and a function pointer
>>> together is simple and obvious, and surely has prior art.
>>
>> D's delegate scheme is essentially the same as described by Richard
>> Hickey, "C++ report" (Feb 1995).
>>
>> See also a discussion on comp.std.c++, Feb 1996, titled "Generic Object
>> Callbacks". Ian Willmott states:
>> "I suggest that a new data type needs to be added to the language. We
>> could call it "pointer-to-bound-member-function".
>> ...
>> Conceptually, it is a two-element structure consisting of
>> pointer into data space, identifying an object, and a pointer into
>> code space, identifying a member function on that object. The static
>> type of such a variable is the signature (return type and arguments)
>> of the member functions it is compatible with, just as the type of a
>> regular function pointer is the signature of the functions it can
>> reference. The only operations defined for this type are assignment,
>> equality, and callthrough. Static typechecking is done at the point
>> where a value of this type is created, and where a call is made
>> through it. "
>>
>> Borland's patent dates from Feb 6, 2001. They were SIX YEARS too late.
>> <g>
>
> IIUC, the structure you describe is /exactly/ the same, both concretely  
> and semantically as Oberon-2 "type-bound procedures" (read: virtual  
> methods). Oberon-2 was created in 1991, IIRC. This makes 10 years ;-)
> Unlike you, I don't consider D's delegate to follow the same scheme.  
> Sure, it's a pair of pointers, one of which point to a routine (to use a  
> neutral word). But in the case of D the second one does not point to to  
> a type/object, but to the definition scope (environment). This is very  
> different, isn't it?

The pointer could be an object:

class C
{
   int x;
   void foo() {x = 5;}
}

void main()
{
   auto c = new C;
   auto dg = &c.foo; // context pointer is pointer to c, not main's stack  
frame
}

Really, the context pointer could be anything.

-Steve