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)

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

regards
ml

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.

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 ?

If either Florian or Peter give their blessing, I can commit the patch?

Michael.

Quoting Michael Van Canneyt :

Daytime jobs? :) Well, isn't everybody:)
The effects of not being applied are even trickier.

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.

regards
ml

---------------------------------------------------------------------- This mail sent through Horde-Toaster (http://qmailtoaster.clikka.com/)

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.

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.

Michael.

No, the root of COM objects is IUnknown, IDispatch is optional for any COM object afaik.

Regards,
Thomas

Correct.

Michael.

Michael Van Canneyt :

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.

No trouble, it means that all interface features I'm implementing will probably (multilpe inheritance, object properties, interface handlers) go there (if accepted). It just means that I have more time to fit your needs better.

2. As a side effect, it allows assigning any class to any class, which is definitely wrong.

Easy fix, what do you need a compiler or runtime error? If I find time it may be today, but surely until start of the next week (I will not have my notebook where I'll reside, just public terminal). If I get it correctly, compiler error.

Ok, no flexibility (:Doing other features too, and I didn't test object to object:) That was the reason for my try to ask questions "how would you like?" (I think that I at least 4 times asked whom to talk about how to implement). Now you finally said how. And patch will be corrected to fit constraints.

It is not my project and the last thing I would like would be enforcing unwanted boundaries (or the lack of it, it can still exist as my patch).

regards
ml

---------------------------------------------------------------------- This mail sent through Horde-Toaster (http://qmailtoaster.clikka.com/)

Sorry, currently I'am very busy with work and life ;( and I've still some other patches pending to review ...

Any examples when this causes problems/why it is removed?

Quoting Florian Klaempfl :

Yeah, here is a no brainerr.

type
  IA = interface
   ['{GUID NUMBER HERE']
   procedure A;
  end;
  TA = class(TInterfacedObject,IA)
    procedure A;
  end;
procedure TA.A;
begin
end;
var
  a,c: IA;
  b:TA;
begin
  b := TA.Create;
  a := b;
  c := b;
  a := b;
  c := b;
  a := b;
  c := b;
  a := b;
  c := b;
  Writeln('refount is ': b.refcount);
end.

Sorry, but I'm on public terminal
Refcount will be correct if guid won't be specified, but as soon as you specify, well you'll see

---------------------------------------------------------------------- This mail sent through Horde-Toaster (http://qmailtoaster.clikka.com/)