Re: [fpc-devel] Improved RTTI compromise

2016-12-09 21:53 GMT+01:00 Sven Barth : > Also when you have extended the unit and provide your changes: please > use baby steps, not one big patch to rule them all ;) > Thanks for tips for tests. I will start new topic - we need to discuss one critical aspect... -- Best regards, Maciej Izak __

Re: [fpc-devel] Improved RTTI compromise

On 07.12.2016 11:31, Maciej Izak wrote: > Okay then, maybe I'll manage that this week (no promise though ;) ). > I personally think that removing TRttiContext for now is the better > choice, so people will know not to use it while they might expect valid > values in the other case..

Re: [fpc-devel] Improved RTTI compromise

Am 07.12.2016 11:31 schrieb "Maciej Izak" : >> Okay then, maybe I'll manage that this week (no promise though ;) ). >> I personally think that removing TRttiContext for now is the better >> choice, so people will know not to use it while they might expect valid >> values in the other case... > > >

Re: [fpc-devel] Improved RTTI compromise

On 07.12.2016 16:16, Jonas Maebe wrote: > On 07/12/16 14:38, Sven Barth wrote: >> But aside from that you could indeed already start to implement >> Invoke(), maybe based on the mORMot code. > > That code is also in fpc/branches/interfacertti. But as mentioned in > earlier threads about this, I th

Re: [fpc-devel] Improved RTTI compromise

On 07/12/16 14:38, Sven Barth wrote: But aside from that you could indeed already start to implement Invoke(), maybe based on the mORMot code. That code is also in fpc/branches/interfacertti. But as mentioned in earlier threads about this, I think it should be generalised in a way that does n

Re: [fpc-devel] Improved RTTI compromise

On Wed, 7 Dec 2016, Sven Barth wrote: Am 07.12.2016 13:58 schrieb "Michael Van Canneyt" : On Wed, 7 Dec 2016, Sven Barth wrote: Trying to generate the exact same information as Delphi is IMHO not the right path. What is needed is an API that gives you the info contained in the int

Re: [fpc-devel] Improved RTTI compromise

Am 07.12.2016 13:58 schrieb "Michael Van Canneyt" : > > > > On Wed, 7 Dec 2016, Sven Barth wrote: > >>> Trying to generate the exact same information as Delphi is IMHO not the >> >> right path. >>> >>> >>> What is needed is an API that gives you the info contained in the >> >> internal structures.

Re: [fpc-devel] Improved RTTI compromise

Am 07.12.2016 11:31 schrieb "Maciej Izak" : > > 2016-12-06 23:39 GMT+01:00 Sven Barth : >> >> Most Delphi code probably uses the RTTI unit anyway for this. And when >> playing with the RTTI one needs to keep track of FPC vs. Delphi anyway >> cause we'll never be 100% compatible (e.g. the Interface

Re: [fpc-devel] Improved RTTI compromise

2016-12-07 9:45 GMT+01:00 Arnaud Bouchez : > Don't forget that there is some working code of interface "Invoke" and > "fake" in mORMot.pas: > - working with FPC_HAS_EXTENDEDINTERFACERTTI or manual-registered RTTI, > - x86 and x64 support on Windows and Linux ABI > - ARM 32-bit and 64-bit (prelimin

Re: [fpc-devel] Improved RTTI compromise

On Wed, 7 Dec 2016, Michael Van Canneyt wrote: On Wed, 7 Dec 2016, Sven Barth wrote: Trying to generate the exact same information as Delphi is IMHO not the right path. What is needed is an API that gives you the info contained in the internal structures. That's what the RTTI unit is

Re: [fpc-devel] Improved RTTI compromise

On Wed, 7 Dec 2016, Maciej Izak wrote: 2016-12-07 8:49 GMT+01:00 Michael Van Canneyt : I am not sure this is possible. The structures exposed in the typinfo interfacee mimic the info the compiler generates in the binary. If the compiler generates different info than Delphi, you cannot retri

Re: [fpc-devel] Improved RTTI compromise

On Wed, 7 Dec 2016, Sven Barth wrote: Trying to generate the exact same information as Delphi is IMHO not the right path. What is needed is an API that gives you the info contained in the internal structures. That's what the RTTI unit is there for. It provides a higher level API to the ty

Re: [fpc-devel] Improved RTTI compromise

2016-12-07 8:49 GMT+01:00 Michael Van Canneyt : > > I am not sure this is possible. The structures exposed in the typinfo > interfacee mimic the info the compiler generates in the binary. > > If the compiler generates different info than Delphi, you cannot retrieve > it in a delphi-compatible way.

Re: [fpc-devel] Improved RTTI compromise

2016-12-06 23:39 GMT+01:00 Sven Barth : > Most Delphi code probably uses the RTTI unit anyway for this. And when > playing with the RTTI one needs to keep track of FPC vs. Delphi anyway > cause we'll never be 100% compatible (e.g. the Interface RTTI branch > does not keep in mind parameters that m

Re: [fpc-devel] Improved RTTI compromise

Don't forget that there is some working code of interface "Invoke" and "fake" in mORMot.pas: - working with FPC_HAS_EXTENDEDINTERFACERTTI or manual-registered RTTI, - x86 and x64 support on Windows and Linux ABI - ARM 32-bit and 64-bit (preliminary) support - well tested under Windows, good cov

Re: [fpc-devel] Improved RTTI compromise

Am 07.12.2016 08:50 schrieb "Michael Van Canneyt" : > > > > On Tue, 6 Dec 2016, Maciej Izak wrote: > >> 2016-12-06 17:46 GMT+01:00 Michael Van Canneyt : >> >>> The Delphi TypInfo unit also exposes the attributes. >> >> >> >> My message was unclear - I mean that we can hide incompatible part of >> T

Re: [fpc-devel] Improved RTTI compromise

On Tue, 6 Dec 2016, Maciej Izak wrote: 2016-12-06 17:46 GMT+01:00 Michael Van Canneyt : The Delphi TypInfo unit also exposes the attributes. My message was unclear - I mean that we can hide incompatible part of TypInfo. Type TAttributeData is located in TypInfo (sooner or later that part

Re: [fpc-devel] Improved RTTI compromise

On 06.12.2016 23:27, Maciej Izak wrote: > 2016-12-06 22:49 GMT+01:00 Sven Barth >: > > We won't need Invoke() function for attributes, since Joost's branch > generates a function that calls the attribute class' constructor with > the provided values

Re: [fpc-devel] Improved RTTI compromise

2016-12-06 22:49 GMT+01:00 Sven Barth : > We won't need Invoke() function for attributes, since Joost's branch > generates a function that calls the attribute class' constructor with > the provided values and returns the created instance. > This has the advantage that it's a) faster and b) works o

Re: [fpc-devel] Improved RTTI compromise

On 06.12.2016 21:17, Maciej Izak wrote: > > 2016-12-06 17:46 GMT+01:00 Michael Van Canneyt >: > > The Delphi TypInfo unit also exposes the attributes. > > > My message was unclear - I mean that we can hide incompatible part of > TypInfo. Type TAttributeData i

Re: [fpc-devel] Improved RTTI compromise

2016-12-06 17:46 GMT+01:00 Michael Van Canneyt : > The Delphi TypInfo unit also exposes the attributes. My message was unclear - I mean that we can hide incompatible part of TypInfo. Type TAttributeData is located in TypInfo (sooner or later that part of TypInfo will be corrected - but IIRC for

Re: [fpc-devel] Improved RTTI compromise

On Tue, 6 Dec 2016, Maciej Izak wrote: Hi, I was thinking about extended RTTI, and important RTTI.pas module (good start point with attributes is waiting 3 years). Seems that the only real reason why we don't have yet RTTI.pas in trunk is incompatibility of generated type info (as Jonas said:

[fpc-devel] Improved RTTI compromise

Hi, I was thinking about extended RTTI, and important RTTI.pas module (good start point with attributes is waiting 3 years). Seems that the only real reason why we don't have yet RTTI.pas in trunk is incompatibility of generated type info (as Jonas said: TAttributeData vs TAttrData, no TAttrEntry)