Re: [fpc-pascal] Traits Proposal
Am 14.02.2021 um 19:22 schrieb Ryan Joseph via fpc-pascal: On Feb 14, 2021, at 11:14 AM, Sven Barth via fpc-pascal wrote: It's a runtime conversion, but normally you don't do the conversion for every method call, but instead cache the interface (or work solely with the interface), thus the performance impact through the conversion amortizes (and again, there's so memory allocation by the conversion itself, of course if the interface getter in case of a interface delegation does a lazy initialization that's different, but the conversion itself does not require an allocation). For default properties no conversion needs to take place even because the compiler can simply find the correct method and return a modified self which points to the struct, like "self.fMyRec" in the example below. In this case the interface doesn't really do anything does it? I think the VMT table is modified and you should probably use CORBA interface unless you want reference counting and extra baggage when you instantiate the class (I assume). If we use records then the memory should be unified (which is good) and with CORBA interfaces no significant baggage during instantiation. Correct me where I'm wrong please. Again, the point of the interface would be to control which methods and properties of the delegated type would be available. Also it would allow for seamless integration with the RTTI as it's possible to query the implemented interface of a class and to retrieve a reference to it, thus it would be possible to access this at runtime as well. The compiler will generate a VMT for the interface with method thunks that adjust the Self pointer so that it works correctly. The GetInterfaceByEntry function uses this static data to generate an adjusted Self value that callers can use. Also for the difference between COM and raw interfaces the only real difference is that a call to _AddRef will be inserted. But I agree that it should also work with raw interfaces (if it doesn't already). Regards, Sven ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Traits Proposal
Am 15.02.2021 um 18:08 schrieb Ryan Joseph via fpc-pascal: On Feb 15, 2021, at 9:08 AM, Marcos Douglas B. Santos via fpc-pascal wrote: As I understand, this is not a method hiding, but just to tell the compiler which method to implement the interface—the interface could have method names which are very very common to use and this syntax allows us to "rename" those methods without changing the original names that the class might have. yeah you may be right, that the interface object itself won't be hookup correctly if this doesn't happen. Seems strange you have 2 declarations for the same method though. procedure IMyIntf.Test2 = MyTest2; propcedure MyTest2; instead of something like: propcedure MyTest2 override IMyIntf.Test2; Because the first one is much more powerful. As Marco said, you can reference a method in the parent class. Also you can redirect different interface methods to the same method: === code begin === type IMyIntf1 = interface procedure Foo; end; IMyIntf2 = interface procedure Bar; end; TMyClass = class(TInterfacedObject, IMyIntf1, IMyIntf2) public procedure IMyIntf1.Foo = Foobar; procedure IMyIntf2.Bar = Foobar; procedure Foobar; end; === code end === Regards, Sven ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Traits Proposal
Am 15.02.2021 um 16:52 schrieb Ryan Joseph via fpc-pascal: On Feb 14, 2021, at 11:43 PM, Sven Barth via fpc-pascal wrote: Same names should be rejected. Providing a new implementation can be controlled using the interface alias: === code begin === type TMyClass = class(TInterfacedObject, IMyIntf) private fMyRecord: TMyRecord; public procedure IMyIntf.Test2 = MyTest2; // this will hoist all methods except Test2 from TMyRecord and MyTest2 as Test2 from the class itself property MyRecord: TMyRecord read fMyRecord implements IMyIntf; default; propcedure MyTest2; end; So "procedure IMyIntf.Test2 = MyTest2;" basically tells the compiler to ignore the duplicate name resections and then when it encounters the MyTest2 there is no error? No, it tells the compiler to fullfill the IMyIntf.Test2 requirement by using TMyClass.MyTest2 instead of TMyRecord.Test2. This way you can control which methods are from the delegate and which might be specific to the container class. It also allows to differentiate if you have two interfaces with the same method: === code begin === type IMyIntf1 = interface procedure Test; end; IMyIntf2 = interface procedure Test; end; TMyClass = class(TInterfacedObject, IMyIntf1, IMyIntf2) public procedure IMyIntf1.Test = Foobar; procedure Test; // for IMyIntf2 procedure Foobar; // for IMyIntf1 end; === code end === A duplicate name in this context is basically just method hiding (like in normal OOP) so you could argue it should be allowed. If the property came before then the interface would hide the local declaration. Not too different from how normal inheritance works really. It should only hide if the method in question is from a parent class. For the declarations in the same class there should be errors, cause the implementor should know better than to introduce potentially ambigious situations. Regards, Sven ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] compiling on command line linux
Am 15.02.2021 um 22:54 schrieb Alexander Grotewohl via fpc-pascal: There's a command line parameter.. try something like fpc -FU~/.units.lnx yourapp.pp Just to explain what -FUxxx does: this sets the unit output path. If you have precompiled units (or source files) in a different location you need to use -Fuxxx which sets the unit search path. Of course you would have to remember to do that for EVERY compile (I set my text editor to do it) but you could probably add it to your fpc.cfg too. You can add additional parameters to a custom file (just like you'd do with the global fpc.cfg) and then add it using the @ parameter: fpc @your.cfg yourapp.pp Regards, Sven ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] compiling on command line linux
There's a command line parameter.. try something like fpc -FU~/.units.lnx yourapp.pp Of course you would have to remember to do that for EVERY compile (I set my text editor to do it) but you could probably add it to your fpc.cfg too. -- Alexander Grotewohl https://dcclost.com From: fpc-pascal on behalf of duilio foschi via fpc-pascal Sent: Monday, February 15, 2021 2:20:28 PM To: FPC-Pascal users discussions Cc: duilio foschi Subject: [fpc-pascal] compiling on command line linux Today I had to compile a program on my Linux server. The program was written for windows and needed libraries synapse and lazutils, and they were missing from the server. I copied all the needed units from my PC into the linux work directory and it worked with the usual command fpc programname.pp Unfortunately now my work directory is messy with tens of units (belonging to libraries synapse and lazutils) unworthily mixed with my poor code. I guess that the kosher way is to create directories lazutils and synapse somewhere in the server but ... where? Where should libraries be copied in linux? How to make them accessible to the compiler? Sorry for being so ignorant... I know how to do it in Lazarus on windows, but fpc on linux is rather arcane to me :) Thank you Duilio ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
[fpc-pascal] compiling on command line linux
Today I had to compile a program on my Linux server. The program was written for windows and needed libraries synapse and lazutils, and they were missing from the server. I copied all the needed units from my PC into the linux work directory and it worked with the usual command fpc programname.pp Unfortunately now my work directory is messy with tens of units (belonging to libraries synapse and lazutils) unworthily mixed with my poor code. I guess that the kosher way is to create directories lazutils and synapse somewhere in the server but ... where? Where should libraries be copied in linux? How to make them accessible to the compiler? Sorry for being so ignorant... I know how to do it in Lazarus on windows, but fpc on linux is rather arcane to me :) Thank you Duilio ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Traits Proposal
Op 2021-02-15 om 18:08 schreef Ryan Joseph via fpc-pascal: As I understand, this is not a method hiding, but just to tell the compiler which method to implement the interface—the interface could have method names which are very very common to use and this syntax allows us to "rename" those methods without changing the original names that the class might have. yeah you may be right, that the interface object itself won't be hookup correctly if this doesn't happen. Seems strange you have 2 declarations for the same method though. procedure IMyIntf.Test2 = MyTest2; propcedure MyTest2; instead of something like: propcedure MyTest2 override IMyIntf.Test2; The first syntax allows to for methods to be declared in the ancestor too. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Traits Proposal
> On Feb 15, 2021, at 9:08 AM, Marcos Douglas B. Santos via fpc-pascal > wrote: > > As I understand, this is not a method hiding, but just to tell the > compiler which method to implement the interface—the interface could > have method names which are very very common to use and this syntax > allows us to "rename" those methods without changing the original > names that the class might have. yeah you may be right, that the interface object itself won't be hookup correctly if this doesn't happen. Seems strange you have 2 declarations for the same method though. procedure IMyIntf.Test2 = MyTest2; propcedure MyTest2; instead of something like: propcedure MyTest2 override IMyIntf.Test2; Regards, Ryan Joseph ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Traits Proposal
On Mon, Feb 15, 2021 at 12:52 PM Ryan Joseph via fpc-pascal wrote: > > > On Feb 14, 2021, at 11:43 PM, Sven Barth via fpc-pascal > > wrote: > > > > Same names should be rejected. Providing a new implementation can be > > controlled using the interface alias: > > > > === code begin === > > > > type > > TMyClass = class(TInterfacedObject, IMyIntf) > > private > > fMyRecord: TMyRecord; > > public > > procedure IMyIntf.Test2 = MyTest2; > > // this will hoist all methods except Test2 from TMyRecord and MyTest2 > > as Test2 from the class itself > > property MyRecord: TMyRecord read fMyRecord implements IMyIntf; default; > > propcedure MyTest2; > > end; > > So "procedure IMyIntf.Test2 = MyTest2;" basically tells the compiler to > ignore the duplicate name resections and then when it encounters the MyTest2 > there is no error? > > A duplicate name in this context is basically just method hiding (like in > normal OOP) so you could argue it should be allowed. If the property came > before then the interface would hide the local declaration. Not too different > from how normal inheritance works really. > As I understand, this is not a method hiding, but just to tell the compiler which method to implement the interface—the interface could have method names which are very very common to use and this syntax allows us to "rename" those methods without changing the original names that the class might have. Marcos Douglas ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Traits Proposal
> On Feb 14, 2021, at 11:43 PM, Sven Barth via fpc-pascal > wrote: > > Same names should be rejected. Providing a new implementation can be > controlled using the interface alias: > > === code begin === > > type > TMyClass = class(TInterfacedObject, IMyIntf) > private > fMyRecord: TMyRecord; > public > procedure IMyIntf.Test2 = MyTest2; > // this will hoist all methods except Test2 from TMyRecord and MyTest2 as > Test2 from the class itself > property MyRecord: TMyRecord read fMyRecord implements IMyIntf; default; > propcedure MyTest2; > end; So "procedure IMyIntf.Test2 = MyTest2;" basically tells the compiler to ignore the duplicate name resections and then when it encounters the MyTest2 there is no error? A duplicate name in this context is basically just method hiding (like in normal OOP) so you could argue it should be allowed. If the property came before then the interface would hide the local declaration. Not too different from how normal inheritance works really. Regards, Ryan Joseph ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
