Re: [fpc-devel] Considerations about observer [was: Free Pascal 2.6.2 rc1]
Once upon a time, on 11/28/2012 03:40 PM to be precise, luiz americo pereira camara said: >>> So, i keep my points. Even because is not a big change with easy >>> implementation that will fix the above issues. >> >> It IS a big change. There is production code out there that uses this, >> and this is an incompatible change. > 1) The change in code can be tedious but is simple. from Attach(MyObj) > to Attach(MyObj as IFPObserver) To fix incompatibility wouldn't a simple operator overload do the trick? Operator := (a: TObject): IFPObserver; or something like that? -- Ewald ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Considerations about observer [was: Free Pascal 2.6.2 rc1]
>>> On 2012-11-27 16:19, Michael Van Canneyt wrote: > > > Correct. But the design should also not try to cover all possible use cases > at any cost. > > Till now, I have not seen a common use case that will not work. See Test1 in a separate message i sent. It will not work with the current implementation >> I just proposed a change that will give more flexibility for the >> programmer when designing his application interface. As a plus with >> less typecasts, so less overhead. > > > If we assume for a second that the internal change to store the interface > instead of the instance is done: > > There are not less typecasts executed, they are in a different place simply. > You must always type the typecast before calling AttachObserver, I do it > inside AttachObserver. My code is therefore simpler to read, generates less > code and hence is preferable. See Test2 in the message i sent. The same Obj is tested for IFPObserver 7 times while would be one > > movq$_$PROGRAM$_Ld1,%rsi > movqU_$P$PROGRAM_$$_C,%rdi > callfpc_class_as_corbaintf > movq%rax,%rdi > callP$PROGRAM_$$_DOI$MYI > > This kind of code you will generate for each call to > AttachObserver/DetachObserver. Not necessarily. Using GetInterface or Supports will avoid the direct typecast Plus: 1) Currently if you don't know before hand if the object implements IFPObserver (most cases), you will have to do the check in the caller anyway 2) Like in Test1 (see other message) there'll be cases that no check or typecast, by the caller or by the callee, will be done at all > So, not requiring the interface to be passed on saves code if you use corba > interfaces. Using COM classes would generate even more code for each > invokation. > > Just to show why I prefer to avoid COM interfaces and the whole 'as' when > possible. Just to be clear: i'm not proposing to use COM interfaces BTW: CORBA interfaces does not requires TGUID so you can remove: GUIDObserved : TGUID = BaseGUIDObserved; GUIDObserver : TGUID = BaseGUIDObserver; > If it had been possible to implement the whole observer thing without using > interfaces, I would have done it, but alas... Yep. The first time i saw the generated code for interface i think: "God: i will never use this". Today i use in selected cases. Luiz ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Considerations about observer [was: Free Pascal 2.6.2 rc1]
On Wed, 28 Nov 2012, luiz americo pereira camara wrote:
2012/11/28 Graeme Geldenhuys :
On 2012-11-27 16:19, Michael Van Canneyt wrote:
If you haven't made other changes to those LCL Mediators since the code
you emailed me, I could take a look at updating the code for Lazarus too.
That's a perfect example of the FPC Observers support being fully
functional as-is.
I don't discuss being fully functional as is. But you must agree that,
if an architeture works in a scenario does not mean it's good or at
least could not be improved.
Correct.
But the design should also not try to cover all possible use cases at any cost.
Till now, I have not seen a common use case that will not work.
I just proposed a change that will give more flexibility for the
programmer when designing his application interface. As a plus with
less typecasts, so less overhead.
If we assume for a second that the internal change to store the interface
instead of the instance is done:
There are not less typecasts executed, they are in a different place simply.
You must always type the typecast before calling AttachObserver, I do it
inside AttachObserver.
My code is therefore simpler to read, generates less code and hence is preferable.
I'm not speaking idly about less code generated. Interfaces generate
some overhead. COM interfaces generate even quite some overhead.
Compare this (not meant to be runnable):
---
{$mode objfpc}
uses classes;
Procedure DoI(I : IInterface);
begin
I._addref;
end;
Var
C : TComponent;
begin
DoI(C as IInterface);
end.
---
With this:
---
{$mode objfpc}
uses classes;
Procedure DoI(C : TComponent);
begin
(C as IInterface)._addref;
end;
Var
C : TComponent;
begin
DoI(C);
end.
---
The latter (no interface passed on) generates the following assembler
for the main program:
movqU_$P$PROGRAM_$$_C,%rdi
callP$PROGRAM_$$_DOI$TCOMPONENT
The former (pass an interface) generates for the main program the following
assembler:
movq$0,-104(%rbp)
leaq-24(%rbp),%rdx
leaq-88(%rbp),%rsi
movq$1,%rdi
callFPC_PUSHEXCEPTADDR
movq%rax,%rdi
callFPC_SETJMP
movq%rax,-96(%rbp)
testl %eax,%eax
jne .Lj10
movq_$PROGRAM$_Ld1,%rdx
movq_$PROGRAM$_Ld1+8,%rcx
movqU_$P$PROGRAM_$$_C,%rsi
leaq-104(%rbp),%rdi
callfpc_class_as_intf
movq-104(%rbp),%rdi
callP$PROGRAM_$$_DOI$IUNKNOWN
.Lj10:
callFPC_POPADDRSTACK
leaq-104(%rbp),%rdi
callfpc_intf_decr_ref
movq-96(%rbp),%rax
testq %rax,%rax
je .Lj11
callFPC_RERAISE
.Lj11:
If you use corba interfaces, then the interface version of the main program is
reduced to
movq$_$PROGRAM$_Ld1,%rsi
movqU_$P$PROGRAM_$$_C,%rdi
callfpc_class_as_corbaintf
movq%rax,%rdi
callP$PROGRAM_$$_DOI$MYI
This kind of code you will generate for each call to
AttachObserver/DetachObserver.
So, not requiring the interface to be passed on saves code if you use corba interfaces.
Using COM classes would generate even more code for each invokation.
Just to show why I prefer to avoid COM interfaces and the whole 'as' when
possible.
If it had been possible to implement the whole observer thing without using
interfaces, I would have done it, but alas...
Michael.
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Considerations about observer [was: Free Pascal 2.6.2 rc1]
On 2012-11-28 15:25, luiz americo pereira camara wrote: > if an architeture works in a scenario does not mean it's good or at > least could not be improved. I'm not disputing that either. It just seems that Michael and I have been using observers in production code for many years. The FPC design is very similar to what we have in production code for years. And with our experience we don't see an immediate issue in the current FPC Observer design. Of course there is a chance that we could be wrong - that is why I asked that you supply a test project we can look at. > I believe such feature at a low level class must be as generic and > flexible as possible. If the design minimizes performance issues > better yet. Agreed. Regards, - Graeme - -- fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal http://fpgui.sourceforge.net/ ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Considerations about observer [was: Free Pascal 2.6.2 rc1]
2012/11/28 Graeme Geldenhuys : > On 2012-11-27 16:19, Michael Van Canneyt wrote: >> > If you haven't made other changes to those LCL Mediators since the code > you emailed me, I could take a look at updating the code for Lazarus too. > > That's a perfect example of the FPC Observers support being fully > functional as-is. > I don't discuss being fully functional as is. But you must agree that, if an architeture works in a scenario does not mean it's good or at least could not be improved. I just proposed a change that will give more flexibility for the programmer when designing his application interface. As a plus with less typecasts, so less overhead. I believe such feature at a low level class must be as generic and flexible as possible. If the design minimizes performance issues better yet. Luiz ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Considerations about observer [was: Free Pascal 2.6.2 rc1]
On 2012-11-28 15:02, luiz americo pereira camara wrote: > > Given that better discuss / test / change such important change > earlier than later, nothing stops to treat this release as a beta (or > whatever name is appropriate) even if was formally released as a RC. [Not related to the issue in question] Indeed, just because it is tagged as RC doesn't mean everything must be cast in stone. A RC tag is *not* an official release yet. Nothing stops the FPC team from creating another 10 RC releases before the official FPC 2.6.2 - and maybe fixing last minute critical bugs etc. The more important thing is to get the issue at hand [if there is one] resolved. Many developers don't use Trunk, and only start testing new FPC releases when RC's are announced. Yes, this is definitely not ideal for the FPC team, but this is often how it works - roll with it. Regards, - Graeme - -- fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal http://fpgui.sourceforge.net/ ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Considerations about observer [was: Free Pascal 2.6.2 rc1]
On 28 Nov 2012, at 16:02, luiz americo pereira camara wrote: 2012/11/28 Jonas Maebe : Personally, I think a release candidate is too late. A release candidate freezes all interfaces (even a beta release does so already, normally). Generally the only fixes still performed afterwards are for blocking crashers/failures, major security holes or build issues. Yes. This proposed change breaks the concept of release candidate. My point here is this is the first release open for wide test with this feature. The first release of new features in FPC always happens via the svn repository. That is the moment to test them and give feedback. Once they end up in a release, they are final. Daily snapshots of FPC that can be used for testing are available from the Lazarus project. Given that better discuss / test / change such important change earlier than later, nothing stops to treat this release as a beta (or whatever name is appropriate) even if was formally released as a RC. The appropriate name would be "alpha". What stops treating the release candidate as an alpha and making invasive changes to it, is that this would significantly slow down the release process (every time we ship a release candidate, someone could pop and say "hey, please change this RC to an alpha version and add/change this -- this would also discourage people from testing the svn versions, since they'd assume they can always delay the release if there's something they don't like). The only possible alternative in this case that I can see would be to remove the new feature altogether from the release (that's still a change, but one thta changes things back to the situation of the previous release and hence is known to be "stable"). However, from what I read from Michael's replies, that would not help since he does not seem to be inclined to change things. Jonas___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Considerations about observer [was: Free Pascal 2.6.2 rc1]
2012/11/28 Jonas Maebe : > > > Personally, I think a release candidate is too late. A release candidate > freezes all interfaces (even a beta release does so already, normally). > Generally the only fixes still performed afterwards are for blocking > crashers/failures, major security holes or build issues. Yes. This proposed change breaks the concept of release candidate. My point here is this is the first release open for wide test with this feature. A feature that lives in a low level class and is supposed to be a standard in fpc development. Given that better discuss / test / change such important change earlier than later, nothing stops to treat this release as a beta (or whatever name is appropriate) even if was formally released as a RC. Luiz ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Considerations about observer [was: Free Pascal 2.6.2 rc1]
2012/11/28 Graeme Geldenhuys : > Luiz, could you produce a small sample application (or show the code you > are working on for Lazarus) where you think the current FPC Observer > implementation doesn't work. Your initial bug report doesn't include any > test project to show the issue. Yes. I'll do later today. Luiz ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Considerations about observer [was: Free Pascal 2.6.2 rc1]
2012/11/28 : > > > On Tue, 27 Nov 2012, luiz americo pereira camara wrote: > >> 2012/11/27 Michael Van Canneyt : >> As practical example take a LCL Form that is supposed to be observed. >> It takes an Observer property and attach it to certain child controls >> (TEdit etc) >> >> 1) Currently i'm forced to declare as the Observer property as an >> TObject. If i declare Observer property as IFPObserver i cannot attach >> to children controls. > > I do not understand this ? > I can post a simple example showing what i mean I'll do today later. Currently i don't have access for a computer with fpc >> 2) Each time i attach to a child control this Observer property will >> be queried to see if implements IFPObserver (but we already know that >> it implements, we already checked !!!) > > > You only gain speed when notifying. When calling FPOAttachAbserver or > FPODetachAbserver, you would need to typecast some object anyway if we would > change the interface, so there is no speed gain there... In this case there's a gain. The typecast would be done once when setting the parent property (IFPObserver) Afterwards (setting children) would be no typecast, different as today > > During notification, we can gain speed by internally storing the interface. > OK. Seems here that we pacify the point of the reference count (not) requirement to store the interface pointer > >> So, i keep my points. Even because is not a big change with easy >> implementation that will fix the above issues. > > > It IS a big change. There is production code out there that uses this, > and this is an incompatible change. 1) The change in code can be tedious but is simple. from Attach(MyObj) to Attach(MyObj as IFPObserver) 2) I 'm assuming this as the first public release for wide test so the best moment for such change Luiz ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Considerations about observer [was: Free Pascal 2.6.2 rc1]
On Wed, 28 Nov 2012, Marco van de Voort wrote: In our previous episode, michael.vancann...@wisa.be said: At some point, there must be an object, and at some point, there is a typecast, You often can't reroot external components, but if they support tcomponent What does "reroot external components" mean ? (Change the root of their inheritance tree. e.g. something that doesn't inherit from interfacedobject to inherit from it) (and thus Tinterfacedobject), you can add an interface in a child class. The interfaces are CORBA, so there is no need for TInterfacedObject. Ok. I assumed they also had to be COM compatible because of tiopf. That the interface is CORBA was a conscious decision so reference counting and all the overhead associated with it was avoided. As far as I know, this rules out COM provided interfaces (if this is what you refer to by external components). That is a tradeoff I find acceptable. For me personally that is unacceptable. But that is not with just an FPC hat on. The probability of using COM with the observer interface is IMHO almost zero. That's simply not the main intended use case, in casu: GUI elements observing business objects: both will normally be in-process. Given the benefit of no reference counting and all that implies (TInterfacedObject etc), it was obvious that CORBA interfaces were the way to go. Michael. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Considerations about observer [was: Free Pascal 2.6.2 rc1]
On 2012-11-27 16:19, Michael Van Canneyt wrote: > > The consequence is that you must pass around the objects themselves. I'm curious to see Luiz's code example of what issues he has, but in the mean time, maybe it wouldn't be such a bad idea to update (with latest FPC changes and Observer support) the LCLMediators code and demos you emailed me a couple years back. [time permitting of course] If you haven't made other changes to those LCL Mediators since the code you emailed me, I could take a look at updating the code for Lazarus too. That's a perfect example of the FPC Observers support being fully functional as-is. Regards, - Graeme - -- fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal http://fpgui.sourceforge.net/ ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Considerations about observer [was: Free Pascal 2.6.2 rc1]
On Wed, Nov 28, 2012 at 5:23 AM, Vincent Snijders wrote: > 2012/11/28 >> It IS a big change. There is production code out there that uses this, >> and this is an incompatible change. > > Then Luiz is right on time with his proposal, with the frist release > candidate of the first release that contains this feature. If > production code already uses it, then the production code writers must > have taken a risk for change knowing that this was a not yet released > feature. +1 >> >> I can change the internals so speed is gained during notifyobservers, >> but I do not see sufficient reasons to change the interface and introduce an >> incompatibility. > > Incompatibility with not yet released code? I agree. Marcos Douglas ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Considerations about observer [was: Free Pascal 2.6.2 rc1]
In our previous episode, michael.vancann...@wisa.be said: > >> At some point, there must be an object, and at some point, there is a > >> typecast, > > > > You often can't reroot external components, but if they support tcomponent > > What does "reroot external components" mean ? (Change the root of their inheritance tree. e.g. something that doesn't inherit from interfacedobject to inherit from it) > > (and thus Tinterfacedobject), you can add an interface in a child class. > > The interfaces are CORBA, so there is no need for TInterfacedObject. Ok. I assumed they also had to be COM compatible because of tiopf. > That the interface is CORBA was a conscious decision so reference counting > and all the overhead associated with it was avoided. As far as I know, this > rules out COM provided interfaces (if this is what you refer to by external > components). That is a tradeoff I find acceptable. For me personally that is unacceptable. But that is not with just an FPC hat on. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Considerations about observer [was: Free Pascal 2.6.2 rc1]
On 28 Nov 2012, at 09:23, Vincent Snijders wrote: 2012/11/28 It IS a big change. There is production code out there that uses this, and this is an incompatible change. Then Luiz is right on time with his proposal, with the frist release candidate of the first release that contains this feature. Personally, I think a release candidate is too late. A release candidate freezes all interfaces (even a beta release does so already, normally). Generally the only fixes still performed afterwards are for blocking crashers/failures, major security holes or build issues. I do believe that maybe this functionality was put in a release too soon after being committed to trunk, given that it changes the interface of the base units and hence the changes are more or less cemented once they are released. But that's a separate issue, which at best can be taken into account in the future. Jonas___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Considerations about observer [was: Free Pascal 2.6.2 rc1]
On 2012-11-28 10:07, Graeme Geldenhuys wrote:
>
> You can add a CORBA interface to any existing class, and it doesn't need
> to descend from TInterfacedObject either. CORBA is not COM interfaces.
>
In case anybody is in doubt. Here is a small example where CORBA
interfaces are attached to TComponent (aka TInterfacedObject
descendants) and TObject classes.
With CORBA interfaces - unlike COM interfaces - we can extend *any*
class. A lot more useful!
8<-8<-8<-8<-8<
MyShape was created
MyShape is being freed
MyShape was created
AttachObserver called - MyShape
MyShape is being freed
MyNonInterfacedObjectClass was created
AttachObserver called - MyNonInterfacedObjectClass
MyNonInterfacedObjectClass is being freed
8<-8<-8<-8<-8<
Regards,
- Graeme -
--
fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal
http://fpgui.sourceforge.net/
program test;
{$mode objfpc}{$h+}
{$ifdef mswindows}
{$apptype console}
{$endif}
{$interfaces corba}
uses
Classes, SysUtils;
type
IObserved = interface
['{5DEEE4A1-8D50-4EA2-96C6-E47EFB65A563}']
procedure AttachObserver(AObserver: TObject);
end;
{ 3rd party component - out of our control }
TShape = class(TComponent)
private
FName: string;
public
constructor Create(const AName: string); virtual; reintroduce;
property Name: string read FName write FName;
end;
{ my personal extensions }
TSquare = class(TShape, IObserved)
private
FSize: integer;
{ IObserved interface }
procedure AttachObserver(AObserver: TObject);
public
property Size: integer read FSize write FSize;
end;
{ my non-TInterfacedObject class }
TMyClass = class(TObject, IObserved)
private
FName: string;
{ IObserved interface }
procedure AttachObserver(AObserver: TObject);
public
property Name: string read FName write FName;
end;
{ TShape }
constructor TShape.Create(const AName: string);
begin
inherited Create(nil);
FName := AName;
end;
procedure TSquare.AttachObserver(AObserver: TObject);
begin
writeln('AttachObserver called - ', Name);
end;
{ TMyClass }
procedure TMyClass.AttachObserver(AObserver: TObject);
begin
writeln('AttachObserver called - ', Name);
end;
var
s1: TShape;
s2: TSquare;
s3: TMyClass;
intf: IObserved;
begin
{ Lets try the Shape first }
s1 := TShape.Create('MyShape');
writeln(s1.Name + ' was created');
if Supports(s1, IObserved, intf) then
intf.AttachObserver(nil);
writeln(s1.Name + ' is being freed');
s1.Free;
writeln('');
{ now lets try the Square }
s2 := TSquare.Create('MyShape');
writeln(s2.Name + ' was created');
if Supports(s2, IObserved, intf) then
intf.AttachObserver(nil);
writeln(s2.Name + ' is being freed');
s2.Free;
writeln('');
{ now lets try the the non-TInterfacedObject class }
s3 := TMyClass.Create;
s3.Name := 'MyNonInterfacedObjectClass';
writeln(s3.Name + ' was created');
if Supports(s3, IObserved, intf) then
intf.AttachObserver(nil);
writeln(s3.Name + ' is being freed');
s3.Free;
writeln('');
end.
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Considerations about observer [was: Free Pascal 2.6.2 rc1]
On 2012-11-28 09:41, Marco van de Voort wrote: > > You often can't reroot external components, but if they support tcomponent > (and thus Tinterfacedobject), you can add an interface in a child class. You can add a CORBA interface to any existing class, and it doesn't need to descend from TInterfacedObject either. CORBA is not COM interfaces. Regards, - Graeme - -- fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal http://fpgui.sourceforge.net/ ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Considerations about observer [was: Free Pascal 2.6.2 rc1]
On Wed, 28 Nov 2012, Marco van de Voort wrote: In our previous episode, michael.vancann...@wisa.be said: Then Luiz is right on time with his proposal, with the frist release candidate of the first release that contains this feature. If production code already uses it, then the production code writers must have taken a risk for change knowing that this was a not yet released feature. It's rather the opposite. This code was developed and has been in use since years. I simply integrated the code in the classes unit, making the production code simpler. Yes, and by doing that you submit it to public scrutiny, risking other opinions. Sure. Based on feedback, the interface was already changed slightly, but not in a super invasive way as asked here. Apart from that, I don't see the point in changing it to an interface. At some point, there must be an object, and at some point, there is a typecast, You often can't reroot external components, but if they support tcomponent What does "reroot external components" mean ? (and thus Tinterfacedobject), you can add an interface in a child class. The interfaces are CORBA, so there is no need for TInterfacedObject. That the interface is CORBA was a conscious decision so reference counting and all the overhead associated with it was avoided. As far as I know, this rules out COM provided interfaces (if this is what you refer to by external components). That is a tradeoff I find acceptable. I can see the speed argument when notifying, but that can be changed by an internal change, without API changes. As Paul and Vincent correctly state, from the view of the FPC project, the interface is not yet fixed. Correct. But I want to see some stronger reasons than the ones given before I change the API. Like I said: The one about speed in notifyupdates is not a problem, I'll improve that, implementation speed is important. Michael. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Considerations about observer [was: Free Pascal 2.6.2 rc1]
On 2012-11-28 08:23, Vincent Snijders wrote: > production code already uses it, then the production code writers must > have taken a risk for change knowing that this was a not yet released > feature. +1 I thought it was a known fact that if you use FPC Trunk in production code, you stand a very likely chance that your production code will be broken at some point. Nothing in FPC Trunk is cast in stone. Though I must admit, this code has been around for some time (at least in my Inbox). I can see where Luiz is coming from. Most Observer implementations seem to be based on interfaces - but that is no hard and fast rule. I also understand Michael's point that AddObserver() and AttachObserver() doesn't need to take interfaces as a parameter. Most developers think that all Interface code is reference counted, but this is simply not true. eg: CORBA interfaces, which is used internally for the Observer support in FPC. The FPC implementation is very similar to what we have in tiOPF for many years, and there it works very well. Though in tiOPF the AttachObserver() and DetachObserver() parameters are a class type we know supports the the observer interface. In FPC this is not the case, though still not a show-stopper. You simply need to double check with a few Supports(obj, IFPObserved, intf) calls where needed. Luiz, could you produce a small sample application (or show the code you are working on for Lazarus) where you think the current FPC Observer implementation doesn't work. Your initial bug report doesn't include any test project to show the issue. Regards, - Graeme - -- fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal http://fpgui.sourceforge.net/ ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Considerations about observer [was: Free Pascal 2.6.2 rc1]
In our previous episode, michael.vancann...@wisa.be said: > > Then Luiz is right on time with his proposal, with the frist release > > candidate of the first release that contains this feature. If > > production code already uses it, then the production code writers must > > have taken a risk for change knowing that this was a not yet released > > feature. > > It's rather the opposite. This code was developed and has been in use since > years. I simply integrated the code in the classes unit, making the > production code simpler. Yes, and by doing that you submit it to public scrutiny, risking other opinions. > Apart from that, I don't see the point in changing it to an interface. > At some point, there must be an object, and at some point, there is a > typecast, You often can't reroot external components, but if they support tcomponent (and thus Tinterfacedobject), you can add an interface in a child class. > I can see the speed argument when notifying, but that can be changed by > an internal change, without API changes. As Paul and Vincent correctly state, from the view of the FPC project, the interface is not yet fixed. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Considerations about observer [was: Free Pascal 2.6.2 rc1]
On Wed, 28 Nov 2012, Vincent Snijders wrote: 2012/11/28 It IS a big change. There is production code out there that uses this, and this is an incompatible change. Then Luiz is right on time with his proposal, with the frist release candidate of the first release that contains this feature. If production code already uses it, then the production code writers must have taken a risk for change knowing that this was a not yet released feature. It's rather the opposite. This code was developed and has been in use since years. I simply integrated the code in the classes unit, making the production code simpler. Apart from that, I don't see the point in changing it to an interface. At some point, there must be an object, and at some point, there is a typecast, this is unavoidable. Nothing is gained by changing the API to use an interface. I can see the speed argument when notifying, but that can be changed by an internal change, without API changes. Michael. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Considerations about observer [was: Free Pascal 2.6.2 rc1]
28.11.2012 16:23, Vincent Snijders wrote: 2012/11/28 It IS a big change. There is production code out there that uses this, and this is an incompatible change. Then Luiz is right on time with his proposal, with the frist release candidate of the first release that contains this feature. If production code already uses it, then the production code writers must have taken a risk for change knowing that this was a not yet released feature. This is exactly my minds. Best regards, Paul Ishenin ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Considerations about observer [was: Free Pascal 2.6.2 rc1]
2012/11/28 > It IS a big change. There is production code out there that uses this, > and this is an incompatible change. Then Luiz is right on time with his proposal, with the frist release candidate of the first release that contains this feature. If production code already uses it, then the production code writers must have taken a risk for change knowing that this was a not yet released feature. > > I can change the internals so speed is gained during notifyobservers, > but I do not see sufficient reasons to change the interface and introduce an > incompatibility. Incompatibility with not yet released code? Vincent ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Considerations about observer [was: Free Pascal 2.6.2 rc1]
On Tue, 27 Nov 2012, luiz americo pereira camara wrote: 2012/11/27 Michael Van Canneyt : On Tue, 27 Nov 2012, luiz americo pereira camara wrote: Hi, i requested a change to observer interface with some considerations in http://bugs.freepascal.org/view.php?id=23394 It will not happen. If you want to pass around interfaces safely, then you need to implement them as descendents of IUnknown to maintain reference counts. They are implemented as CORBA interfaces exactly to avoid the overhead of IUnknown. The consequence is that you must pass around the objects themselves. I don't see the point. It would be true if the IFPObserved (e.g., TPersistent) takes ownership of the attached observers. That is not the case. Currently, in the observer feature, there's no difference between plain TObject and corba interface (IFPObserver) regarding the life cycle management. Correct. Both there are no guarantees that they will still be alive when accessed. The current approach limits the programmer flexibility and adds unnecessary overhead. As practical example take a LCL Form that is supposed to be observed. It takes an Observer property and attach it to certain child controls (TEdit etc) 1) Currently i'm forced to declare as the Observer property as an TObject. If i declare Observer property as IFPObserver i cannot attach to children controls. I do not understand this ? 2) Each time i attach to a child control this Observer property will be queried to see if implements IFPObserver (but we already know that it implements, we already checked !!!) You only gain speed when notifying. When calling FPOAttachAbserver or FPODetachAbserver, you would need to typecast some object anyway if we would change the interface, so there is no speed gain there... During notification, we can gain speed by internally storing the interface. So, i keep my points. Even because is not a big change with easy implementation that will fix the above issues. It IS a big change. There is production code out there that uses this, and this is an incompatible change. I can change the internals so speed is gained during notifyobservers, but I do not see sufficient reasons to change the interface and introduce an incompatibility. Michael. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Considerations about observer [was: Free Pascal 2.6.2 rc1]
2012/11/27 Michael Van Canneyt : > > > On Tue, 27 Nov 2012, luiz americo pereira camara wrote: > >> >> Hi, i requested a change to observer interface with some >> considerations in http://bugs.freepascal.org/view.php?id=23394 > > > It will not happen. > > If you want to pass around interfaces safely, then you need to implement > them as > descendents of IUnknown to maintain reference counts. They are implemented > as CORBA interfaces exactly to avoid the overhead of IUnknown. > > The consequence is that you must pass around the objects themselves. I don't see the point. It would be true if the IFPObserved (e.g., TPersistent) takes ownership of the attached observers. That is not the case. Currently, in the observer feature, there's no difference between plain TObject and corba interface (IFPObserver) regarding the life cycle management. Both there are no guarantees that they will still be alive when accessed. The current approach limits the programmer flexibility and adds unnecessary overhead. As practical example take a LCL Form that is supposed to be observed. It takes an Observer property and attach it to certain child controls (TEdit etc) 1) Currently i'm forced to declare as the Observer property as an TObject. If i declare Observer property as IFPObserver i cannot attach to children controls. 2) Each time i attach to a child control this Observer property will be queried to see if implements IFPObserver (but we already know that it implements, we already checked !!!) _Every_ time a child control notify it's observers _each_ observer will be checked again if implements IFPObserver (it would not even be there if not's the case!!!) To detach the observer is the same: is checked if implements IFPObserver yet another time So, i keep my points. Even because is not a big change with easy implementation that will fix the above issues. PS: please at least consider my points. The impression is that you even did not read my considerations, just took your previous conclusions and throw away after reading the title. I'm just trying to help make a better design. Luiz ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Considerations about observer [was: Free Pascal 2.6.2 rc1]
- Original Message - > From: Graeme Geldenhuys > To: fpc-devel@lists.freepascal.org > Cc: > Sent: Tuesday, November 27, 2012 2:29 PM > Subject: Re: [fpc-devel] Considerations about observer [was: Free Pascal > 2.6.2 rc1] > > On 2012-11-27 17:17, Leonardo M. Ramé wrote: >> >> Hi, does anyone know of a link to the wiki with info about the newly > implemented Observer pattern?. >> > > No wiki page, but I did submit in the mailing list and Mantis a observer > demo with code comments to show how it works and how to use it. > > > http://bugs.freepascal.org/view.php?id=23329 > > > Regards, > - Graeme - > Thanks. Leonardo M. Ramé http://leonardorame.blogspot.com ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Considerations about observer [was: Free Pascal 2.6.2 rc1]
On 2012-11-27 17:17, Leonardo M. Ramé wrote: > > Hi, does anyone know of a link to the wiki with info about the newly > implemented Observer pattern?. > No wiki page, but I did submit in the mailing list and Mantis a observer demo with code comments to show how it works and how to use it. http://bugs.freepascal.org/view.php?id=23329 Regards, - Graeme - -- fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal http://fpgui.sourceforge.net/ ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Considerations about observer [was: Free Pascal 2.6.2 rc1]
- Original Message - > From: Michael Van Canneyt > To: FPC developers' list > Cc: > Sent: Tuesday, November 27, 2012 1:19 PM > Subject: Re: [fpc-devel] Considerations about observer [was: Free Pascal > 2.6.2 rc1] > > > > On Tue, 27 Nov 2012, luiz americo pereira camara wrote: > >> 2012/11/13 Marco van de Voort : >>> >>> Hello, >>> >>> We have placed the first release-candidate of the Free Pascal Compiler >>> version 2.6.2 on our ftp-servers. >> >> [..] >> >> >>> * Support for observer pattern added to fcl-base (and base classes in > RTL) >> >> Hi, i requested a change to observer interface with some >> considerations in http://bugs.freepascal.org/view.php?id=23394 > > It will not happen. > > If you want to pass around interfaces safely, then you need to implement them > as > descendents of IUnknown to maintain reference counts. They are implemented as > CORBA > interfaces exactly to avoid the overhead of IUnknown. > > The consequence is that you must pass around the objects themselves. > > Michael. Hi, does anyone know of a link to the wiki with info about the newly implemented Observer pattern?. -- Leonardo M. Ramé http://leonardorame.blogspot.com ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Considerations about observer [was: Free Pascal 2.6.2 rc1]
On Tue, 27 Nov 2012, luiz americo pereira camara wrote: 2012/11/13 Marco van de Voort : Hello, We have placed the first release-candidate of the Free Pascal Compiler version 2.6.2 on our ftp-servers. [..] * Support for observer pattern added to fcl-base (and base classes in RTL) Hi, i requested a change to observer interface with some considerations in http://bugs.freepascal.org/view.php?id=23394 It will not happen. If you want to pass around interfaces safely, then you need to implement them as descendents of IUnknown to maintain reference counts. They are implemented as CORBA interfaces exactly to avoid the overhead of IUnknown. The consequence is that you must pass around the objects themselves. Michael. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel] Considerations about observer [was: Free Pascal 2.6.2 rc1]
2012/11/13 Marco van de Voort : > > Hello, > > We have placed the first release-candidate of the Free Pascal Compiler > version 2.6.2 on our ftp-servers. [..] > * Support for observer pattern added to fcl-base (and base classes in RTL) Hi, i requested a change to observer interface with some considerations in http://bugs.freepascal.org/view.php?id=23394 I still playing with it and can have more considerations later Luiz ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
