"Don" <nos...@nospam.com> wrote in message news:ihcrve$1t5l$1...@digitalmars.com... > 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've been under the impression that, as a rule, the USPTO doesn't check for prior art and deliberately leaves "invalid due to prior art" up to the courts.