Potential patent issues

[Daniel Gibson]

Am 21.01.2011 21:06, schrieb spir:
> 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?

You're thinking of closures (which are also "delegates" in D), but D's delegates 
can also be used to simple point to a member of an object.
It's kind of hidden in the definition:

"Delegates to non-static nested functions contain two pieces of data: the 
pointer to the stack frame of the lexically enclosing function (called the frame 
pointer) and the address of the function.
_This is analogous to struct/class non-static member function delegates 
consisting of a this pointer and the address of the member function._
Both forms of delegates are interchangeable, and are actually the same type: [...]"

from http://www.digitalmars.com/d/2.0/function.html

> 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...
>
> Denis
> _________________
> vita es estrany
> spir.wikidot.com
>