[fpc-pascal] Corba Interfaces and IInterface query
Hi,
Below is an example of two interfaces I declared. Trying to implement
them on a TObject subclass, I got a compiler error that IUnkown was
not implemented in my subclass. In all units I defined {$interfaces
corba}
Eventually I found out that I had to remove the (IInterface) heritage
from my interface definitions. Why is IInterface bound to IIUnknown
(aka COM interfaces)? In Delphi 7+ and Kylix, IInterface was not a COM
interface, so I would have expected that to be usable in CORBA
interfaces in FPC too, but apparently not. So what's the point of
having IInterface then if it is always bound to COM? In that case,
simply defined your interfaces from IUnkown as per the COM spec.
--
unit layout_interface;
{$mode objfpc}{$h+}
{$interfaces corba}
interface
uses
Classes, fpg_base;
type
ILayoutManager = interface; // forward declaration
ILayoutManaged = interface(IInterface)
['{05680C87-FD6A-4E41-84CE-ADD66DB60F8E}']
function GetLayoutManager: ILayoutManager;
procedure SetLayout(ALayout: ILayoutManager);
property Layout: ILayoutManager read GetLayoutManager;
end;
ILayoutManager = interface(IInterface)
['{91FF6CE0-3B18-470A-BBCF-476064891EE4}']
procedure AddWidget(AWidget: TfpgWindowBase);
procedure AddLayout(ALayout: ILayoutManager);
end;
implementation
end.
--
--
Regards,
- Graeme -
___
fpGUI - a cross-platform Free Pascal GUI toolkit
http://opensoft.homeip.net:8080/fpgui/
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Corba Interfaces and IInterface query
On 14.11.2010 11:52, Graeme Geldenhuys wrote:
Hi,
Below is an example of two interfaces I declared. Trying to implement
them on a TObject subclass, I got a compiler error that IUnkown was
not implemented in my subclass. In all units I defined {$interfaces
corba}
Eventually I found out that I had to remove the (IInterface) heritage
from my interface definitions. Why is IInterface bound to IIUnknown
(aka COM interfaces)? In Delphi 7+ and Kylix, IInterface was not a COM
interface, so I would have expected that to be usable in CORBA
interfaces in FPC too, but apparently not. So what's the point of
having IInterface then if it is always bound to COM? In that case,
simply defined your interfaces from IUnkown as per the COM spec.
It's Delphi compatible:
http://docwiki.embarcadero.com/VCL/XE/en/System.IInterface
So yes, it seems to be a COM interface even in Delphi 7+ (I don't know
about Kylix though).
Regards,
Sven
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Corba Interfaces and IInterface query
On 14 November 2010 13:03, Sven Barth wrote: > > It's Delphi compatible: > http://docwiki.embarcadero.com/VCL/XE/en/System.IInterface > > So yes, it seems to be a COM interface even in Delphi 7+ (I don't know about > Kylix though). I don't know that the latest Embarcadero docs say, but IInterface was introduced when Kylix was created. Kylix runs under Linux where COM doesn't exist. So IInterface was not COM driven, and as far as I know, it was made the same under Delphi to, so Kylix and Delphi are consistent in that regard. -- Regards, - Graeme - ___ fpGUI - a cross-platform Free Pascal GUI toolkit http://opensoft.homeip.net:8080/fpgui/ ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] Is it posible to implement more than one interface in a class defination?
For example if there are two Interface : IinterfaceA,IinterfaceB can I implement these two interface in one class? Thanks pingyu ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Corba Interfaces and IInterface query
On 14.11.2010 13:03, Graeme Geldenhuys wrote: On 14 November 2010 13:03, Sven Barth wrote: It's Delphi compatible: http://docwiki.embarcadero.com/VCL/XE/en/System.IInterface So yes, it seems to be a COM interface even in Delphi 7+ (I don't know about Kylix though). I don't know that the latest Embarcadero docs say, but IInterface was introduced when Kylix was created. Kylix runs under Linux where COM doesn't exist. So IInterface was not COM driven, and as far as I know, it was made the same under Delphi to, so Kylix and Delphi are consistent in that regard. According to this mail from 2007 http://www.mail-archive.com/fpc-de...@lists.freepascal.org/msg04158.html IInterface and IUnknown are the same in Delphi 7 as well as they are in FPC (although they are aliased the other way round, but that doesn't matter). So I still say it's Delphi compatible ^^ Regards, Sven ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Is it posible to implement more than one interface in a class defination?
On 14.11.2010 13:08, yu ping wrote: For example if there are two Interface : IinterfaceA,IinterfaceB can I implement these two interface in one class? Yes, you can. Take the following example: type IInterfaceA = interface procedure A; end; IInterfaceB = interface procedure B; end; TMyInterfacedObject = class(TInterfacedObject, IInterfaceA, IInterfaceB) public procedure A; procedure B; end; Regards, Sven ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Corba Interfaces and IInterface query
On 14 November 2010 14:18, Sven Barth wrote: > IInterface and IUnknown are the same in Delphi 7 as well as they are in FPC > (although they are aliased the other way round, but that doesn't matter). So then comes the big question — why have IInterface then, if it is exactly the same as IUnknown, yet not a known COM interface name? > So I still say it's Delphi compatible Is it just me or is this phrase getting a bit monotonous. -- Regards, - Graeme - ___ fpGUI - a cross-platform Free Pascal GUI toolkit http://opensoft.homeip.net:8080/fpgui/ ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Is it posible to implement more than one interface in a class defination?
On 14 November 2010 14:08, yu ping wrote: > For example if there are two Interface : IinterfaceA,IinterfaceB > can I implement these two interface in one class? Yes you can, but be warned, Interfaces doesn't seem to be a high priority feature in FPC - I don't think many here use Interfaces. There are still some very strange things or missing features in FPC's implementation. Even though Interfaces are an extremely handy language feature in Delphi and often used, just be careful under FPC. -- Regards, - Graeme - ___ fpGUI - a cross-platform Free Pascal GUI toolkit http://opensoft.homeip.net:8080/fpgui/ ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Corba Interfaces and IInterface query
On 14.11.2010 14:16, Graeme Geldenhuys wrote: On 14 November 2010 14:18, Sven Barth wrote: IInterface and IUnknown are the same in Delphi 7 as well as they are in FPC (although they are aliased the other way round, but that doesn't matter). So then comes the big question — why have IInterface then, if it is exactly the same as IUnknown, yet not a known COM interface name? Ask Borland why they decided to do it that way... perhaps they wanted a common ancestor for they case they ever decide to use non COM interfaces... (I can only guess here) So I still say it's Delphi compatible Is it just me or is this phrase getting a bit monotonous. The point is that this is the reason for many things in Free Pascal. It doesn't matter whether you like that reason or not. You and I either have to live with that or do something against it (you might argue that not everything is accepted, but that is not the topic here). Exceptions are mostly Generics, operator overloading and more generic enumerators (and the stricter syntax in *fpc modes). Oh, and let's not forget the existence of non-COM interfaces and the new constref parameter modifier. :) Regards, Sven ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] MSEide+MSEgui rev.2.4
Martin Schreiber wrote: Hi, MSEide+MSEgui version 2.4 for FPC 2.4.2 has been released: https://developer.berlios.de/project/showfiles.php?group_id=11520 Questions and bug reports please to mailing list: https://lists.berlios.de/mailman/listinfo/mseide-msegui-talk NNTP gateway: nntp://news.gmane.org/gmane.comp.ide.mseide.user Mail achive: http://www.mail-archive.com/mseide-msegui-t...@lists.berlios.de/ Have a lot of fun! Martin This is a new page with FPC 2.4.2 and fpGUI: http://www.turbocontrol.com/easyfpgui.htm I'd like to set up a similar page for MSEgui (and maybe for MSEide as well). Please contact me off-list about this. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Corba Interfaces and IInterface query
On 14 November 2010 15:36, Sven Barth wrote: > > Ask Borland why they decided to do it that way... perhaps they wanted a > common ancestor for they case they ever decide to use non COM interfaces... > (I can only guess here) This is exactly what I am saying IInterface is a non-COM interface in Kylix (so that would seem logical why they introduced IInterface, and not keep using IUnkown because the latter would make no sense under Linux), and will mostly like be the case again when Embarcadero brings out their x-platform Delphi. So with FPC already supporting COM and non-COM interfaces, it would seem logical that when CORBA interfaces are used, IInterface acts the same as Kylix, by being a non-COM interface. I also hate open ended type definitions. eg: TMyClass = class end; That defaults to a TObject descendant. Then in Delphi a interface definition of IMyInterface = interface end; will actually descend from IInterface/IUnknown. But that same interface definition descends from what, when CORBA style interfaces are used in FPC? Just nothing? This doesn't seem logical, hence I think it should also descend from IInterface like Kylix, but then be non-COM. -- Regards, - Graeme - ___ fpGUI - a cross-platform Free Pascal GUI toolkit http://opensoft.homeip.net:8080/fpgui/ ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] MSEide+MSEgui rev.2.4
In our previous episode, Paul Breneman said: > > This is a new page with FPC 2.4.2 and fpGUI: >http://www.turbocontrol.com/easyfpgui.htm > > I'd like to set up a similar page for MSEgui (and maybe for MSEide as > well). Please contact me off-list about this. Btw, you might want to scrap the turboexplorer.com link on your website. The Turbo Explorer versions of Delphi are no longer available, and that page only lists 30 day trials. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Corba Interfaces and IInterface query
In our previous episode, Graeme Geldenhuys said: > This is exactly what I am saying IInterface is a non-COM interface in > Kylix Please leave IInterface alone. It took me a week of work to let the current IInterface=IUnknown alias propagate properly in fpdoc's internal structures :-) ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] Re: MSEide+MSEgui rev.2.4
Paul Breneman wrote: > > I'd like to set up a similar page for MSEgui (and maybe for MSEide as > well). Please contact me off-list about this. Done. Martin ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] MSEide+MSEgui rev.2.4
Marco van de Voort wrote: In our previous episode, Paul Breneman said: This is a new page with FPC 2.4.2 and fpGUI: http://www.turbocontrol.com/easyfpgui.htm I'd like to set up a similar page for MSEgui (and maybe for MSEide as well). Please contact me off-list about this. Btw, you might want to scrap the turboexplorer.com link on your website. The Turbo Explorer versions of Delphi are no longer available, and that page only lists 30 day trials. Thanks for the feedback! I guess I was hoping the Turbo Explorer versions would return at some point... :) ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Corba Interfaces and IInterface query
On 14.11.2010 14:58, Marco van de Voort wrote: In our previous episode, Graeme Geldenhuys said: This is exactly what I am saying IInterface is a non-COM interface in Kylix Please leave IInterface alone. It took me a week of work to let the current IInterface=IUnknown alias propagate properly in fpdoc's internal structures :-) @Graeme: I'd say this is a much better reason than "Delphi compatibility" for not touching the definition of IInterface, don't you think? :D Besides think about the following: Let's say IInterface would be changed to be the base ancestor type for Corba interfaces. What about existing classes that implement IInterface (which currently declares QueryInterface, AddRef and Release, cause IInterface=IUnknown)? Do they suddenly become "Corba implementing" classes? What about code that relies on the fact that reference counting works (although not in the same way as in the recent discussion about that...)? It would be a too big change. Like the resolution for "internal error 200111022" ( http://www.hu.freepascal.org/lists/fpc-devel/2010-October/022478.html and http://bugs.freepascal.org/view.php?id=17675 ) was "allow in all modes" although it would have been nice to disallow that in mode objfpc. It would have broken just to much code. "The damage is done", so to say. If anything than there could be a "ICorbaInterface" addad as a base ancestor for Corba interfaces. But please note that there is another inheritance supporting type that does not have a specific base class: OBJECT. Regards, Sven ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] When do I need a component rather than a plain object?
Does TObject have all the capabilities of TComponent apart from things like streaming and being used from the IDE component palette? I want to create an object which has all the capabilities like getting and setting properties, and I want to know whether I need to inherit from TObject or from something further down the hierarchy. Another aspect is ownership. Does ownership require objects to be derived from TComponent? Is a TPersistent adequate if manipulating the object from the IDE isn't needed? Last but not the least, is the FreePascal TObject/TComponent system more or less the same as Delphi's, or are there some major differences? PS. I asked this question in the Lazarus forum, but on reflection it is a FreePascal question and belongs here instead. -- Frank Church === http://devblog.brahmancreations.com ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Corba Interfaces and IInterface query
On 14 November 2010 15:58, Marco van de Voort wrote: > > Please leave IInterface alone. It took me a week of work to let the current > IInterface=IUnknown alias propagate properly in fpdoc's internal structures > :-) :-) I can't say I saw that one coming. -- Regards, - Graeme - ___ fpGUI - a cross-platform Free Pascal GUI toolkit http://opensoft.homeip.net:8080/fpgui/ ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Corba Interfaces and IInterface query
On 14 November 2010 17:25, Sven Barth wrote:
> Besides think about the following:
>
> Let's say IInterface would be changed to be the base ancestor type for Corba
> interfaces. What about existing classes that implement IInterface (which
> currently declares QueryInterface, AddRef and Release, cause
> IInterface=IUnknown)? Do they suddenly become "Corba implementing" classes?
No, that is controlled by -SI compiler parameter or the {$interfaces
...} directive. By default FPC defaults to COM interfaces on all
platforms, even though Windows is the _only_ OS that has COM.
Considering the amount of platforms FPC supports, FPC is already very
accommodating to Windows users in this regard (and quite biased).
What would be a lot more logical is if FPC defaults to COM based
interfaces under Windows only, which means by default there,
IInterface is a IUnknown descendant and thus COM based.
Under all other OSes, (which don't have COM), FPC should default to
CORBA style interfaces, where IInterface is non-COM - same as what was
done in Kylix. What's the point of have COM style interface on
non-Windows platforms anyway. Reference count can still be implemented
in CORBA interfaces if required by the developer. Simply use
TInterfacedObject for that.
> What about code that relies on the fact that reference counting works
> (although not in the same way as in the recent discussion about that...)?
It will be business as usual, nothing will change. TInterfacedObject
can still be reference counted on all platforms - CORBA style or not.
> http://bugs.freepascal.org/view.php?id=17675 ) was "allow in all modes"
> although it would have been nice to disallow that in mode objfpc. It would
...and such decisions is the start of a downward trend for FPC. Such
code should not be allowed period. FPC's designs should stay logical
and clean, and it's up to the developers to maintain their application
code and fixe such bad/broken code. After all, the one is a property
and the other a function - very different constructs.
Either way, I don't see how this relates to Interfaces.
--
Regards,
- Graeme -
___
fpGUI - a cross-platform Free Pascal GUI toolkit
http://opensoft.homeip.net:8080/fpgui/
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Corba Interfaces and IInterface query
Graeme Geldenhuys schrieb: FPC's designs should stay logical and clean, and it's up to the developers to maintain their application code and fixe such bad/broken code. ... and as soon as we do such a logical decision, you start whining, whining about the bad fpc developers destroying your business plans. See the recent thread on fpc-devel about immediate release of unused temporary interfaces and not keeping them for an unlogical long time. Or did you forget about it already? I fear you did again ... ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Is it posible to implement more than one interface in a class defination?
Hi Everybody, On 14 November 2010 16:31, Jonas Maebe wrote: > Please don't spread FUD. There are several projects that make heavy use of > interfaces that work fine with FPC (e.g. Zeoslib). Yes, interface delegation > is not finished (other than that, interfaces work fine afaik) Let me just clarify. I did not have a "dig" at anybody or the FPC team. I simply wanted to make the original poster aware of the limitation of FPC's Interfaces implementation to date. And no Jonas, there are still plenty of things missing from FPC's implementation, and thus it proves that hardly anybody in the FPC core team uses Interfaces now or in the past. Two major issues (but not the only items I can list): * incomplete delegation (non existent in FPC 2.4.2) * No name resolution (function aliases) of conflicting interfaces Unfortunately these are rather critical features in normal to advanced interface usage in software. If you haven't used them yet, then you have only scratched the surface of what Interfaces are useful for. So at this point, only the most basic usage (aka reference counting - memory management) of Interfaces work in FPC. > after the "interface scoping" thread on fpc-devel). If things continue like > this, I will start holding all of your mails for moderation and only allow > them through on a case-by-case basis, because the current situation is not > tenable. And we here start again. By all means, if it will make you feel better/happier, then why not simply unsubscribe or band my from all FPC and Lazarus related mailing lists while you are at it. For Gods sakes, I was simply trying to help somebody by mentioning potential problems when using FPC's Interfaces in "real world applications". If you come from Delphi or Kylix to Free Pascal, you as a developer should be made aware of these things. In fact, there should actually be a wiki page dedicated to what FPC cannot do compared to Delphi or Kylix. This would seriously help developers wanting to move to Free Pascal, to evaluate FPC better before they make a decision. I see no harm in letting developers know what FPC cannot do yet, this might even help new contributors with ideas of what they can implement so FPC can move forward. -- Regards, - Graeme - ___ fpGUI - a cross-platform Free Pascal GUI toolkit http://opensoft.homeip.net:8080/fpgui/ ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Corba Interfaces and IInterface query
On 14.11.2010 17:30, Graeme Geldenhuys wrote:
On 14 November 2010 17:25, Sven Barth wrote:
Besides think about the following:
Let's say IInterface would be changed to be the base ancestor type for Corba
interfaces. What about existing classes that implement IInterface (which
currently declares QueryInterface, AddRef and Release, cause
IInterface=IUnknown)? Do they suddenly become "Corba implementing" classes?
No, that is controlled by -SI compiler parameter or the {$interfaces
...} directive. By default FPC defaults to COM interfaces on all
platforms, even though Windows is the _only_ OS that has COM.
Considering the amount of platforms FPC supports, FPC is already very
accommodating to Windows users in this regard (and quite biased).
You didn't follow the recent discussions about XPCOM which let to the
introduction of the constref modifier? XPCOM is - as the name suggests -
cross platform COM and now supported by Free Pascal as well.
What would be a lot more logical is if FPC defaults to COM based
interfaces under Windows only, which means by default there,
IInterface is a IUnknown descendant and thus COM based.
Under all other OSes, (which don't have COM), FPC should default to
CORBA style interfaces, where IInterface is non-COM - same as what was
done in Kylix. What's the point of have COM style interface on
non-Windows platforms anyway. Reference count can still be implemented
in CORBA interfaces if required by the developer. Simply use
TInterfacedObject for that.
There is a difference: If I use CORBA interfaces the compiler WON'T
increase/decrease the reference count automatically. That is THE
difference between CORBA and COM interfaces.
What about code that relies on the fact that reference counting works
(although not in the same way as in the recent discussion about that...)?
It will be business as usual, nothing will change. TInterfacedObject
can still be reference counted on all platforms - CORBA style or not.
See above.
http://bugs.freepascal.org/view.php?id=17675 ) was "allow in all modes"
although it would have been nice to disallow that in mode objfpc. It would
...and such decisions is the start of a downward trend for FPC. Such
code should not be allowed period. FPC's designs should stay logical
and clean, and it's up to the developers to maintain their application
code and fixe such bad/broken code. After all, the one is a property
and the other a function - very different constructs.
Either way, I don't see how this relates to Interfaces.
It's not related to interfaces, but related to the fact that something
like your suggestion falls into the category "breaks to much code".
Those solutions will face troubles if presented to the core devs just
like the more clean solution for the "duplicate identifier" problem was
not implemented...
Regards,
Sven
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Corba Interfaces and IInterface query
On 14 November 2010 18:44, Florian Klaempfl wrote: > > ... and as soon as we do such a logical decision, you start whining, whining > about the bad fpc developers destroying your business plans. Bo hoo... It's called being able to maintain code in the long run. Keep adding one hack after the next might solve your problem now, but in a few years you have a unmaintainable piece of software. Windows API is prove of that. Qt and Linux API on the other hand are good examples of keeping API clean even if that means breaking code between major releases. Or did you forget your constant nagging about needing to keep FPC maintainable in the long run... I guess you forgot. -- Regards, - Graeme - ___ fpGUI - a cross-platform Free Pascal GUI toolkit http://opensoft.homeip.net:8080/fpgui/ ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Corba Interfaces and IInterface query
Graeme Geldenhuys schrieb: On 14 November 2010 18:44, Florian Klaempfl wrote: ... and as soon as we do such a logical decision, you start whining, whining about the bad fpc developers destroying your business plans. Bo hoo... It's called being able to maintain code in the long run. Oh, I forgot, depending on implementation details keeps your code maintainable ... ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Is it posible to implement more than one interface in a class defination?
On 14.11.2010 17:49, Graeme Geldenhuys wrote:
* incomplete delegation (non existent in FPC 2.4.2)
I haven't used this for quite a long time, so I can't test it just
now... what are you missing?
* No name resolution (function aliases) of conflicting interfaces
Ehhh... the following code compiles with 2.4.2 and even 2.4.0:
source begin
program interfacetest;
{$mode objfpc}
uses
SysUtils;
type
IMyInterface = interface
procedure Foo;
end;
TMyInterfacedObject = class(TInterfacedObject, IMyInterface)
public
procedure IMyInterface.Foo = Bar;
procedure Bar;
procedure Foo;
end;
procedure TMyInterfacedObject.Bar;
begin
Writeln('Bar');
end;
procedure TMyInterfacedObject.Foo;
begin
Writeln('Foo');
end;
var
t: TMyInterfacedObject;
i: IMyInterface;
begin
t := TMyInterfacedObject.Create;
try
i := t;
t.Foo;
i.Foo;
finally
t.Free;
end;
end.
source end
Output is:
output begin
Foo
Bar
An unhandled exception occurred at $08056B71 :
EInvalidPointer : Invalid pointer operation
$08056B71
output end
(I don't know currently where exactly that EInvalidPointer comes
from even a "t.AddRef" doesn't solve this...)
Regards,
Sven
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Is it posible to implement more than one interface in a class defination?
Sven Barth schrieb: * No name resolution (function aliases) of conflicting interfaces Ehhh... the following code compiles with 2.4.2 and even 2.4.0: Typical FUD tactics: mix something people know being true with something wrong and they believe you the wrong statement. var t: TMyInterfacedObject; i: IMyInterface; begin t := TMyInterfacedObject.Create; try i := t; t.Foo; i.Foo; finally t.Free; end; end. source end Output is: output begin Foo Bar An unhandled exception occurred at $08056B71 : EInvalidPointer : Invalid pointer operation $08056B71 output end (I don't know currently where exactly that EInvalidPointer comes from even a "t.AddRef" doesn't solve this...) Releasing TInterfacedObject descendants by Free is a bad idea ;) It destroys the instance without checking if there are still queried interfaces. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Is it posible to implement more than one interface in a class defination?
On 14.11.2010 18:17, Florian Klaempfl wrote: var t: TMyInterfacedObject; i: IMyInterface; begin t := TMyInterfacedObject.Create; try i := t; t.Foo; i.Foo; finally t.Free; end; end. source end Output is: output begin Foo Bar An unhandled exception occurred at $08056B71 : EInvalidPointer : Invalid pointer operation $08056B71 output end (I don't know currently where exactly that EInvalidPointer comes from even a "t.AddRef" doesn't solve this...) Releasing TInterfacedObject descendants by Free is a bad idea ;) It destroys the instance without checking if there are still queried interfaces. You're right of course... The following code flow works: begin t := TMyInterfacedObject.Create; i := t; t.Foo; i.Foo; end; But why doesn't the following? begin t := TMyInteracedObject.Create; try t._AddRef; i := t; t.Foo; i.Foo; i := Nil; // shouldn't this solve the problem as well? or is this a problem of temp inteface variables? finally t.Free; end; end; Regards, Sven ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Corba Interfaces and IInterface query
On Sunday, 14. November 2010 17.30:13 Graeme Geldenhuys wrote: > Under all other OSes, (which don't have COM), FPC should default to > CORBA style interfaces, where IInterface is non-COM - same as what was > done in Kylix. What's the point of have COM style interface on > non-Windows platforms anyway. Reference count can still be implemented > in CORBA interfaces if required by the developer. Simply use > TInterfacedObject for that. > Reference counted interfaces need compiler magic AFAIK. Martin ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Corba Interfaces and IInterface query
On 14 Nov 2010, at 13:16, Graeme Geldenhuys wrote: > On 14 November 2010 14:18, Sven Barth wrote: >> IInterface and IUnknown are the same in Delphi 7 as well as they are in FPC >> (although they are aliased the other way round, but that doesn't matter). > > > So then comes the big question — why have IInterface then, if it is > exactly the same as IUnknown, yet not a known COM interface name? Delphi 5 supported both "COM" and CORBA. No IInterface, only IUnknown. Delphi 3 supported COM without interfaces at all. When I was still doing Delphi, it was 5. We used to use Interfaces all the time, but we simply reimplemented the TInterfacedObject and ignored the COM methods. We used them much as one would with in .Net these days. More about light public interfaces, encapsulation and delegation rather than ref counting and such. M___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Is it posible to implement more than one interface in a class defination?
On 14 November 2010 19:11, Sven Barth wrote: >> * No name resolution (function aliases) of conflicting interfaces > > Ehhh... the following code compiles with 2.4.2 and even 2.4.0: My apologies then, I must not have seen the announcement. I also looked in my ref.pdf (which was incidentally in a folder 'FPC_DOCS/new/' ) which listed in section 7.3 that it is currently not implemented. After you email, I looked at the title page of that PDF document, I noticed I have a rather old PDF, so the 'new' directory fooled me a bit, and indeed it was not a v2.4.0 version as I thought. I guess it's time I clean out my development directories a bit. -- Regards, - Graeme - ___ fpGUI - a cross-platform Free Pascal GUI toolkit http://opensoft.homeip.net:8080/fpgui/ ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Corba Interfaces and IInterface query
On 14 November 2010 19:49, Martin Schreiber wrote: >> > Reference counted interfaces need compiler magic AFAIK. Indeed, you are correct. -- Regards, - Graeme - ___ fpGUI - a cross-platform Free Pascal GUI toolkit http://opensoft.homeip.net:8080/fpgui/ ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Corba Interfaces and IInterface query
On 14 November 2010 19:45, Matt Emson wrote: > methods. We used them much as one would with in .Net these days. More about > light public interfaces, encapsulation and delegation rather than ref > counting and such. This is how I use interfaces too. I never to COM programming as such, but do you the various features that come with interfaces - as you mentioned. It's great for help out with circular unit reference issues too. -- Regards, - Graeme - ___ fpGUI - a cross-platform Free Pascal GUI toolkit http://opensoft.homeip.net:8080/fpgui/ ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] When do I need a component rather than a plain object?
On Sun, 14 Nov 2010, Frank Church wrote:
Does TObject have all the capabilities of TComponent apart from things like
streaming and being used from the IDE component palette?
I want to create an object which has all the capabilities like getting and
setting properties, and I want to know whether I need to
inherit from TObject or from something further down the hierarchy.
If you need published properties (RTTI) then you can descend from TPersistent.
Or, you create a class that descends from TObject, for instance TRTTIObject
and compile it under {$M+}, and derive all your objects from that.
Another aspect is ownership. Does ownership require objects to be derived from
TComponent?
Yes. Unless you care to re-implement the TComponent behaviour.
Is a TPersistent adequate if manipulating the object from the IDE isn't needed?
Yes.
Last but not the least, is the FreePascal TObject/TComponent system more or
less the same as Delphi's, or are there some major
differences?
It is the same. At least we try very hard to keep it so :-)
Michael.
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Is it posible to implement more than one interface in a class defination?
I suspect the reason is that the object still has a refCount of 1 when you free it and this code raises the exception: procedure TInterfacedObject.BeforeDestruction; begin if frefcount<>0 then HandleError(204); end; You should never free an interfaced object directly. Regards Andrew. On 14 Nov 10, at 09:27 , Sven Barth wrote: > You're right of course... > > The following code flow works: > > begin > t := TMyInterfacedObject.Create; > i := t; > t.Foo; > i.Foo; > end; > > But why doesn't the following? > > begin > t := TMyInteracedObject.Create; > try >t._AddRef; >i := t; >t.Foo; >i.Foo; >i := Nil; // shouldn't this solve the problem as well? or is this a > problem of temp inteface variables? > finally >t.Free; > end; > end; ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] Re: [admin] List moderation (was: Is it posible to implement more than one interface in a class defination?)
On 14 Nov 2010, at 17:49, Graeme Geldenhuys wrote: > By all means, if it will make you feel > better/happier, then why not simply unsubscribe or band my from all > FPC and Lazarus related mailing lists while you are at it. It has nothing to do with with how I feel, although I can't say that I appreciate off-list moderation messages being quoted partially back to the list. I don't hold a grudge against you and there are obviously several areas where you do make useful contributions to the lists (e.g., helping people with fpgui). There is however a problem if more and more threads that you participate in end up as flame wars, draining energy from everyone involved, and even from other people too. For now, messages from you to fpc-pascal and fpc-devel will require moderator approval. Jonas FPC mailing lists admin Below is the complete message I originally sent to Graeme in private. Graeme, Please don't spread FUD. There are several projects that make heavy use of interfaces that work fine with FPC (e.g. Zeoslib). Yes, interface delegation is not finished (other than that, interfaces work fine afaik) and you are extremely unhappy with the way FPC is developed in general (and probably with several core developers in particular), but sending messages like the one below does not help anyone. It's getting to the point where several people are getting really beat down and demotivated by your constant enmity (apart from comments on the mailing lists, I've also received a number of private mails about this, especially after the "interface scoping" thread on fpc-devel). If things continue like this, I will start holding all of your mails for moderation and only allow them through on a case-by-case basis, because the current situation is not tenable. And to clarify: the problem is not criticising as such. Other people, such as Martin Schreiber, also regularly criticise FPC and I'm not aware of anyone having any problems with him. It's how you do that. Jonas FPC mailing lists moderator ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Is it posible to implement more than one interface in a class defination?
FWIW, both interface delegation ("implements") and "method aliasing" have been
supported in FPC for at least 2 years (we first tested/used them in January
2009 with FPC 2.2.2 which was released in August 2008).
* We have used method aliasing extensively - it appears to behave the same as
Borland Delphi and has no issues that we have found.
* FPC's "implements" is limited compared with Borland Delphi (the "implements"
property cannot use method accessors and the field must reference an interface
not a class). Allowing for these limitations, we have not had problems using
this feature (although have not used it "creatively").
Regards Andrew.
On 14 Nov 10, at 08:49 , Graeme Geldenhuys wrote:
> Two major issues (but not the only items I can list):
> * incomplete delegation (non existent in FPC 2.4.2)
> * No name resolution (function aliases) of conflicting interfaces
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
