Potential patent issues

[Don]

spir 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?
> Thus I would consider D to not even be concerned by the patent. If you 
> use a 3-integer struct to store a color, do you have to pay royalties to 
> the owner of a patent about a 3-integer struct used to store a position? 
> Indeed, lawyers...

Yeah. I think we can be certain that that patent has zero risk for D.
On the positive side -- I think that the rise of public source 
repositories (with complete histories) means that public disclosure has 
become much more common (factor of 1000 or more) than the days when 
these junk patents were issued.

Imagine you're a patent examiner, who has to work out if a particular 
code idea has been previously published. How can you be confident that 
it doesn't already exist in the billions of lines of open source code on 
the web? And how much would you charge someone who asked you to check 
them all?

I used to be quite depressed about software patents, but now I just 
don't think they are workable. The prior art is just growing too fast.