[fpc-pascal] interface "is" patch (finished and included)
Michael Van Canneyt
michael.vancanneyt at wisa.be
Fri Apr 1 09:21:25 CEST 2005
On Fri, 1 Apr 2005 ml at brainwashers.org wrote:
> Quoting Michael Van Canneyt <michael at freepascal.org>:
>> On Thu, 31 Mar 2005, ml wrote:
>>> i included again my refcount patch (haven't got even a little response
>>> on it. i'm slowly starting to wonder if i'm on the right mailing list
>>> (usually devel list is for internal purposes of regular developers, and
>>> others are... well,... for others (as well as bug reporting as
>>> patches)), i got more response on C operators (which i didn't even asked
>>> in fact) than on my first patch and error reports in interfaces)
>> The core developers are quite busy people with daytime jobs.
>> The effects of the patch can be quite tricky, which explains
>> probably why they have not yet been applied.
> Daytime jobs? :) Well, isn't everybody:)
> The effects of not being applied are even trickier.
Apparently not. The patch was studied by Peter:
1. It introduces a new feature, and as such will be only intyroduced
after 2.0 has been released.
2. As a side effect, it allows assigning any class to any class,
which is definitely wrong.
>>> would include auto_assign_of_guid patch too, but as much as i ask for
>>> somebody involved in compiler nobody answers, that one requires one
>>> change in lower levels
>> I guess Florian needs to answer this one, or peter.
>> I have downloaded and checked the patch, however I'm not a compiler person.
>> The RTL patch looks OK to me. have you checked what happens with an object
>> passed through COM ?
> COM? as I already said. COM objects have assigned GUID, And refcount gets
> incremented by 2 for those (and refcount is handled by fpc, and not COM), off
> course if it
> would be the case of COM object there's nothing easier than check against
> IDispatch, as
> I see IDispatch should be the root of COM objects with no object in fpc behind
> (at least based on Delphi documentation I got my self about interfaces to check
> Delphi compatibility), second option is to derive basic interface from IUnknown
> (IClassUnknown and this one is
> bound to be referenced with class object behind), I already did that in my other
> patches). In any case patch to include that check would be either 2 or 5 liner.
> In either case refcount isn't working for fpc (not COM) based interfaces that
> don't have GUID 0 (side effect of GUID being 0 is that Supports, GetQuery and
> QueryInterface don't work, maybe fpc should report error for now if no GUID, I
> have a patch for that too).
> But no, I haven't checked. I still have to set up some winblows machine. But
> lately I have too much work to do and as you know: "All work and no fun makes
> Jack a dull boy."
> While on the other hand, "is" is nothing else but checking with GetQuery() and
> QueryInterface(), this one shouldn't make any problems. I checked, rechecked and
> then again checked. I only add two compilerprocs and invoked calling from
> tisnode, where it was denied by default. So if your code works mine does too.
Seems like after the patch too much wrong code is allowed to work as well :)
But I'm not qualified to speak about the compiler patches. Peter or
Florian should do that.
More information about the fpc-pascal