Re: [fpc-devel] RTTI and Attributes in Delphi 2010
On Sun, 16 Aug 2009, Graeme Geldenhuys wrote: Just thought I would let you know... http://www.malcolmgroves.com/blog/?p=476 Hm Website not accessible. Can you give us the gist of what is so interesting ? Michael. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] RTTI and Attributes in Delphi 2010
In our previous episode, Michael Van Canneyt said: Just thought I would let you know... http://www.malcolmgroves.com/blog/?p=476 Hm Website not accessible. Can you give us the gist of what is so interesting ? Has been hinted at several times, so I can make an educated guess: The project is called exRTTI, and provides RTTI for nearly everything, weak linked to avoid bloating, and directives to indicate a non-weak (strong?) linking, in the case of plugin archs etc. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] RTTI and Attributes in Delphi 2010
2009/8/16 Michael Van Canneyt mich...@freepascal.org: Website not accessible. Can you give us the gist of what is so interesting ? Weird. Anyway, I placed the web page content in a OpenDocument Text format available at: http://opensoft.homeip.net/~graemeg/rtti_and_attributes.odt Hope that helps. Regards, - Graeme - ___ fpGUI - a cross-platform Free Pascal GUI toolkit http://opensoft.homeip.net/fpgui/ ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] RTTI and Attributes in Delphi 2010
Graeme Geldenhuys wrote: Just thought I would let you know... http://www.malcolmgroves.com/blog/?p=476 This reminds me our previos discussion about property attributes: http://wiki.lazarus.freepascal.org/Property_attributes Best regards, Paul Ishenin. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] RTTI and Attributes in Delphi 2010
In our previous episode, Michael Van Canneyt said: Just thought I would let you know... http://www.malcolmgroves.com/blog/?p=476 Hm Website not accessible. Can you give us the gist of what is so interesting ? I had that too, but later it worked. Now I've also seen the syntax, and I think sb should explain those Delphi devels that in C-like languages function modifiers come BEFORE the declaration, and in Pascal AFTER :-) ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] RTTI and Attributes in Delphi 2010
2009/8/16 Marco van de Voort mar...@stack.nl: I had that too, but later it worked. Now I've also seen the syntax, and I think sb should explain those Delphi devels that in C-like languages function modifiers come BEFORE the declaration, and in Pascal AFTER :-) Very true! Now lets see what they say on the CodeGear newsgroups. :-) Regards, - Graeme - ___ fpGUI - a cross-platform Free Pascal GUI toolkit http://opensoft.homeip.net/fpgui/ ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] RTTI and Attributes in Delphi 2010
On Sun, 16 Aug 2009, Graeme Geldenhuys wrote: 2009/8/16 Michael Van Canneyt mich...@freepascal.org: Website not accessible. Can you give us the gist of what is so interesting ? Weird. Anyway, I placed the web page content in a OpenDocument Text format available at: http://opensoft.homeip.net/~graemeg/rtti_and_attributes.odt Hope that helps. It does, thank you. However, it's not so spectacular: Attributes are simply old .NET stuff they ported to Win32. Seems they had to use a workaround through an attribute class. I never understood the need for it. RTTI is more than enough for 99.99% of the cases. Michael. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] RTTI and Attributes in Delphi 2010
In our previous episode, Michael Van Canneyt said: It does, thank you. However, it's not so spectacular: Attributes are simply old .NET stuff they ported to Win32. Seems they had to use a workaround through an attribute class. I never understood the need for it. RTTI is more than enough for 99.99% of the cases. Give the customer what he wants. And a customer doesn't know enough to show any restraint. More is always better, and if sb else has it, I also want it. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] RTTI and Attributes in Delphi 2010
2009/8/16 Michael Van Canneyt mich...@freepascal.org: I never understood the need for it. RTTI is more than enough for 99.99% of the cases. I agree 100%. Regards, - Graeme - ___ fpGUI - a cross-platform Free Pascal GUI toolkit http://opensoft.homeip.net/fpgui/ ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] RTTI and Attributes in Delphi 2010
Michael Van Canneyt wrote:
I never understood the need for it. RTTI is more than enough
for 99.99% of the cases.
Imagine you have a db framework which maps delphi classes to database
tables. It reads class properties from the rtti and creates db tables
automatically.
For example:
TStudent = class(TPersistent)
published
property ID: Integer read FID write FID;
property Name: String read FName write FName;
property Age: Integer read FAge write FAge;
property Group: String read FGroup write FGroup;
end;
How db framework can create a table based on this information? It needs
some more info about field types, primary keys.
Now using attributes we can extend our class declaration:
TStudent = class(TPersistent)
published
[TDBField('Integer', 'primary key')]
property ID: Integer read FID write FID;
[TDBField('VarChar(100)')]
property Name: String read FName write FName;
property Age: Integer read FAge write FAge; // db field type can be
guessed from the property type here
[TDBField('VarChar(20)')]
property Group: String read FGroup write FGroup;
end;
This is just one example. If you remember we thought to use property
attributes for the LCL previously.
Best regards,
Paul Ishenin.
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel] patch to call DoneKeyboard in the exitproc of the drivers unit
Does anyone have an idea why the call to DoneKeyboard was previously
commented? It leaves the keyboard in a bad state if the IDE crashes.
Index: packages/fv/src/drivers.pas
===
--- packages/fv/src/drivers.pas (revision 13526)
+++ packages/fv/src/drivers.pas (working copy)
@@ -855,7 +855,7 @@
BEGIN
DoneSysError; { Relase error trap }
DoneEvents;{ Close event driver }
-{ DoneKeyboard;}
+ DoneKeyboard;
DoneVideo;
ExitProc := SaveExit; { Restore old exit }
END;
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] patch to call DoneKeyboard in the exitproc of the drivers unit
On 16 Aug 2009, at 12:15, Nikolay Nikolov wrote: Does anyone have an idea why the call to DoneKeyboard was previously commented? It leaves the keyboard in a bad state if the IDE crashes. It was changed in revision 3443, whose log message says: r3443 | daniel | 2006-05-07 00:57:20 +0200 (Sun, 07 May 2006) | 3 lines Changed paths: M /trunk/fv/app.pas M /trunk/fv/drivers.pas M /trunk/fv/validate.pas M /trunk/ide/fp.pas M /trunk/ide/fpide.pas * Video and keyboard initialization spaghetti organized and hopefully fixed. - Remove useless function from validate.pas Maybe Daniel knows. Jonas ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] RTTI and Attributes in Delphi 2010
In our previous episode, Paul Ishenin said: I never understood the need for it. RTTI is more than enough for 99.99% of the cases. Imagine you have a db framework which maps delphi classes to database tables. It reads class properties from the rtti and creates db tables automatically. For example: TStudent = class(TPersistent) published property ID: Integer read FID write FID; property Name: String read FName write FName; property Age: Integer read FAge write FAge; property Group: String read FGroup write FGroup; end; How db framework can create a table based on this information? It needs some more info about field types, primary keys. I know what .NET uses it for, but that was not the question. The question is why does this have to be solved using a language construct? Why can't you simply register the Object-Relation mapping somewhere else? What is the value of making it RTTI? Sure you can abuse RTTI to hang information on any identifier, and make a nice example out of it, but does that really display the requirement for RTTI? ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] RTTI and Attributes in Delphi 2010
On Sun, 16 Aug 2009, Paul Ishenin wrote: Michael Van Canneyt wrote: I never understood the need for it. RTTI is more than enough for 99.99% of the cases. Imagine you have a db framework which maps delphi classes to database tables. It reads class properties from the rtti and creates db tables automatically. For example: TStudent = class(TPersistent) published property ID: Integer read FID write FID; property Name: String read FName write FName; property Age: Integer read FAge write FAge; property Group: String read FGroup write FGroup; end; How db framework can create a table based on this information? It needs some more info about field types, primary keys. But that needs to be registered separately anyway, because this varies on the storage back-end. The object-db mapping should never be in the object itself, that is bad design. Michael. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] RTTI and Attributes in Delphi 2010
2009/8/16 Paul Ishenin webpi...@mail.ru: Imagine you have a db framework which maps delphi classes to database tables. It reads class properties from the rtti and creates db tables automatically. tiOPF has metadata classes to do just this, but in both cases they work only well if you have quite simple design. Anything complex (and unfortunately my designs seem to be) those property - db field mappings simply don't coupe. I also have tables in by database, where one table contains information for various classes. I have to use tiOPF's hard-coded visitors, so I can manually implement the complex mapping and create/populate the correct classes from a single query. But yeah, I guess for the general public they could have some uses. I haven't found a use for me though (not yet). Regards, - Graeme - ___ fpGUI - a cross-platform Free Pascal GUI toolkit http://opensoft.homeip.net/fpgui/ ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] RTTI and Attributes in Delphi 2010
2009/8/16 Michael Van Canneyt mich...@freepascal.org: But that needs to be registered separately anyway, because this varies on the storage back-end. The object-db mapping should never be in the object itself, that is bad design. +1 And what about classes that can be stored in various backends? For example, in tiOPF the same class can be stored in CSV, Tab delimited, XML or any SQL DB - all with a compiler define or parameter to the application at runtime. Also, foreign keys and primary keys don't mean anything to XML, CSV etc... Regards, - Graeme - ___ fpGUI - a cross-platform Free Pascal GUI toolkit http://opensoft.homeip.net/fpgui/ ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] RTTI and Attributes in Delphi 2010
Marco van de Voort wrote: I know what .NET uses it for, but that was not the question. The question is why does this have to be solved using a language construct? Why can't you simply register the Object-Relation mapping somewhere else? Because it is a more natural way. I want to give full property declaration in a one place. What is the value of making it RTTI? Sure you can abuse RTTI to hang information on any identifier, and make a nice example out of it, but does that really display the requirement for RTTI Currently RTTI is very limited - using it you can only enumerate published members, learn their types and default values (for properties). Attributes completely eliminates limitations. Best regards, Paul Ishenin. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] patch to call DoneKeyboard in the exitproc of the drivers unit
Op Sun, 16 Aug 2009, schreef Jonas Maebe: On 16 Aug 2009, at 12:15, Nikolay Nikolov wrote: Does anyone have an idea why the call to DoneKeyboard was previously commented? It leaves the keyboard in a bad state if the IDE crashes. It was changed in revision 3443, whose log message says: r3443 | daniel | 2006-05-07 00:57:20 +0200 (Sun, 07 May 2006) | 3 lines Changed paths: M /trunk/fv/app.pas M /trunk/fv/drivers.pas M /trunk/fv/validate.pas M /trunk/ide/fp.pas M /trunk/ide/fpide.pas * Video and keyboard initialization spaghetti organized and hopefully fixed. - Remove useless function from validate.pas Maybe Daniel knows. In Turbo Vision, it is the task of Tapplication to initialize drivers and the task of Tprogram to detect how it was initialized. This was totally messed up; i.e. Tprogram.initscreen is supposed to detect the current screen, but people had inserted code into it that did change the screen, so they also invented a donescreen. This caused a lot of bugs inside FV applications. With this patch, I brought things back as they should be, all intialization/finalization back to Tapplication and Tprogram just detects how things are initialized. Daniël___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] RTTI and Attributes in Delphi 2010
On Sun, 16 Aug 2009, Graeme Geldenhuys wrote: 2009/8/16 Michael Van Canneyt mich...@freepascal.org: But that needs to be registered separately anyway, because this varies on the storage back-end. The object-db mapping should never be in the object itself, that is bad design. +1 And what about classes that can be stored in various backends? For example, in tiOPF the same class can be stored in CSV, Tab delimited, XML or any SQL DB - all with a compiler define or parameter to the application at runtime. Also, foreign keys and primary keys don't mean anything to XML, CSV etc... That's what I meant with 'this varies on the storage back-end.'... :-) Michael. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] patch to call DoneKeyboard in the exitproc of the drivers unit
On 08/16/2009 03:22 PM, Daniël Mantione wrote: Op Sun, 16 Aug 2009, schreef Jonas Maebe: On 16 Aug 2009, at 12:15, Nikolay Nikolov wrote: Does anyone have an idea why the call to DoneKeyboard was previously commented? It leaves the keyboard in a bad state if the IDE crashes. It was changed in revision 3443, whose log message says: r3443 | daniel | 2006-05-07 00:57:20 +0200 (Sun, 07 May 2006) | 3 lines Changed paths: M /trunk/fv/app.pas M /trunk/fv/drivers.pas M /trunk/fv/validate.pas M /trunk/ide/fp.pas M /trunk/ide/fpide.pas * Video and keyboard initialization spaghetti organized and hopefully fixed. - Remove useless function from validate.pas Maybe Daniel knows. In Turbo Vision, it is the task of Tapplication to initialize drivers and the task of Tprogram to detect how it was initialized. This was totally messed up; i.e. Tprogram.initscreen is supposed to detect the current screen, but people had inserted code into it that did change the screen, so they also invented a donescreen. This caused a lot of bugs inside FV applications. With this patch, I brought things back as they should be, all intialization/finalization back to Tapplication and Tprogram just detects how things are initialized. This is all cool, but IMHO DoneKeyboard should also be called in the ExitProc to clean things up in case a runtime error occurs, since then the TApplication destructor isn't (usually) called. Is there a reason not to do that? Calling DoneKeyboard twice on normal exit should be safe, as it checks a flag and does nothing when you call it the second time. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] patch to call DoneKeyboard in the exitproc of the drivers unit
Op Sun, 16 Aug 2009, schreef Nikolay Nikolov: On 08/16/2009 03:22 PM, Daniël Mantione wrote: Op Sun, 16 Aug 2009, schreef Jonas Maebe: On 16 Aug 2009, at 12:15, Nikolay Nikolov wrote: Does anyone have an idea why the call to DoneKeyboard was previously commented? It leaves the keyboard in a bad state if the IDE crashes. It was changed in revision 3443, whose log message says: r3443 | daniel | 2006-05-07 00:57:20 +0200 (Sun, 07 May 2006) | 3 lines Changed paths: M /trunk/fv/app.pas M /trunk/fv/drivers.pas M /trunk/fv/validate.pas M /trunk/ide/fp.pas M /trunk/ide/fpide.pas * Video and keyboard initialization spaghetti organized and hopefully fixed. - Remove useless function from validate.pas Maybe Daniel knows. In Turbo Vision, it is the task of Tapplication to initialize drivers and the task of Tprogram to detect how it was initialized. This was totally messed up; i.e. Tprogram.initscreen is supposed to detect the current screen, but people had inserted code into it that did change the screen, so they also invented a donescreen. This caused a lot of bugs inside FV applications. With this patch, I brought things back as they should be, all intialization/finalization back to Tapplication and Tprogram just detects how things are initialized. This is all cool, but IMHO DoneKeyboard should also be called in the ExitProc to clean things up in case a runtime error occurs, since then the TApplication destructor isn't (usually) called. Is there a reason not to do that? Calling DoneKeyboard twice on normal exit should be safe, as it checks a flag and does nothing when you call it the second time. I can see the issue with abnormal program exits, but I disabled it because calling it twice had unintended effects. So we need to verify we don't break anything. Daniël ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Questions regarding PostgreSQL support in SqlDB
Op zaterdag 08-08-2009 om 19:03 uur [tijdzone +0200], schreef Graeme Geldenhuys: 1..) In the function TPQConnection.GetSchemaInfoSQL(..) there is the following SQL statements. * First off, this statement doesn't return a single row when I run it directly in psql or pgAdmin III. * Why are so many fields got the value 0. For example the system table pg_attribute contains most of the information for the fields that return 0. Fields like type, datatype, scale, length, etc... The output of the query has to the same as for the other databases. So that's why several 'empty/0' fields are there. And for type/datatype the value in pg_attribute could have to be translated to the right value. But it's this way because nobody looked at it before, and all those things like column_datatype are effectively used by no-body, afaik. But patches are welcome. (The only reason this function is implemented at all is that it is used by Connection.getTableNames and .GetFieldNames.) stColumns: s := 'select '+ 'a.attnum as recno, '+ ' as catalog_name, '+ ' as schema_name, '+ 'c.relnameas table_name, '+ 'a.attnameas column_name, '+ '0as column_position, '+ '0as column_type, '+ '0as column_datatype, '+ ' as column_typename, '+ '0as column_subtype, '+ '0as column_precision, '+ '0as column_scale, '+ 'a.atttypmod as column_length, '+ 'not a.attnotnull as column_nullable '+ 'from '+ ' pg_class c, pg_attribute a '+ 'WHERE '+ // This can lead to problems when case-sensitive tablenames are used. '(c.oid=a.attrelid) and (a.attnum0) and (not a.attisdropped) and (upper(c.relname)=''' + Uppercase(SchemaObjectName) + ''') ' + 'order by a.attname'; Instead of the above query, why not use the Information Schema views to pull that information out in a much more friendly manner. Here is a quick example... SELECT ordinal_position, column_name, data_type, column_default, is_nullable, character_maximum_length, numeric_precision FROM information_schema.columns WHERE table_name = 'test_table' ORDER BY ordinal_position This probably didn't exist when this code was written (postgres 5) and the information_schema is probably just a view which references to pg_attribute... 2..) Then in function TPQConnection.TranslateFldType(..) we have the following lines... Oid_text : Result := ftBlob; Oid_Bytea : Result := ftBlob; Shouldn't Oid_text return ftMemo instead of ftBlob? Could be. In fact, Bytea is not a blob field. So to support blob-fields, Text was abused. Which is also wrong. But Text isn't memo either. Actually it's a varchar Base problem is that Postgres has a different idea of field-types then the databases you are used to use. (For blob-fields Postgresql ask you to use a plain number-field in which you store the blob-id, and then use seperate functions to retrieve the blob-data. Problem is that sqldb can never map correctly to those blob-fields, because you can never know if a number-field actually contains a reference to a blob-field) But before my vacation i wrote something about making this mapping adjustable. That's still one my investigation list. 3..) In procedure TPQConnection.PrepareStatement(..) there is a const TypeStrings being setup. Many of those entries show unknown when in fact they could probably have PostgreSQL types associated instead. The 16th and 18th item (counting starts at 1) could most probably be bytea instead of unknown. There are a few others as well. Probably they are not used at all, so why bother. ;) But please create bug-reports, preferrably with actual user-case problems, not only based on the code, but also show the results. That way we can find some way to be as compatible possible with other databases like Firebird. Joost. ___
[fpc-devel] csInlin how is it suppossed to work?
Paul Ishenin wrote: Martin wrote: http://bugs.freepascal.org/view.php?id=14364 saving frames with anchorsides (or rather the inability of doing so) Either we do something wrong with csInline flag or it is a but in the FPC. Best regards, Paul Ishenin. Yes it is strange. I am down to rtl\objpas\classes\writer.inc line 599 if (FAncestor is TComponent) then begin FAncestors:=TStringList.Create; if csInline in TComponent(FAncestor).ComponentState then FRootAncestor := TComponent(FAncestor); TComponent(FAncestor).GetChildren(@AddToAncestorList,FRootAncestor); FAncestors.Sorted:=True; end; try Component.GetChildren(@WriteComponent, FRoot); A Frame has csInline = so Frame.Getchildren is called with FRootAncestor (which is the frame itself?) But ALL the children are added to the AnchestorList = is that supposed to be? Because then later: procedure TWriter.WriteComponent(Component: TComponent); DetermineAncestor(Component); will find a random children there and that seems wrong. Martin ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Questions regarding PostgreSQL support in SqlDB
2009/8/16 Joost van der Sluis jo...@cnoc.nl: But it's this way because nobody looked at it before, and all those things like column_datatype are effectively used by no-body, afaik. But patches are welcome. (The only reason this function is implemented at all is that it is used by Connection.getTableNames and .GetFieldNames.) So is SqlDB+PostgreSQL not tested or Alpha / Beta quality? I was hoping to use it in a production environment. PostgreSQL seems to be a lot more powerful than other open source database + the PostgreSQL tools like pgAdmin III are brilliant. This probably didn't exist when this code was written (postgres 5) and the information_schema is probably just a view which references to pg_attribute... Yes, any implementation of information_schema is normally a view. The nice thing is that even if the underlying system tables change, the information_schema views will not. Hence the reason it is preferable to use the information_schema's if they exist, instead of querying the system tables directly. Is it still worth supporting anything before PostgreSQL 7.2 - as far as I can see many major changes (for the better) occurred after 7.2 and 8.0. Hey, the database server is free, so there shouldn't be any reason not to upgrade. :-) Could be. In fact, Bytea is not a blob field. So to support blob-fields, All the documentation I read suggests that Bytea is used for BLOB types. And Firebird's blob subtype 1 is equal to Text in PostgreSQL. the databases you are used to use. (For blob-fields Postgresql ask you to use a plain number-field in which you store the blob-id, and then use seperate functions to retrieve the blob-data. As far as I understood the documentation, that is all handled internally by PostgreSQL. Users do not need to worry about something like that, you use Bytea just like any other field type. The server stores BLOB (bytea) data in a separate location to overcome the table row size limit. Internally a reference is used in the users table, but the end user never sees that. But please create bug-reports, preferrably with actual user-case problems, not only based on the code, but also show the results. That way we can find some way to be as compatible possible with other databases like Firebird. Will do - expect many patches. I'm determined to get Free Pascal to pass the extensive test suite of tiOPF. The database test suite gives the DB components a very good workout. SqlDB+Firebird is doing pretty well, but SqlDB+PostgreSQL still fails a lot of tests. Both are not 100% pass rate, but hopefully when I am done, they will be. Regards, - Graeme - ___ fpGUI - a cross-platform Free Pascal GUI toolkit http://opensoft.homeip.net/fpgui/ ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] RTTI and Attributes in Delphi 2010
2009/8/16 Michael Van Canneyt mich...@freepascal.org: That's what I meant with 'this varies on the storage back-end.'... :-) I was agreeing with you. I simple wanted to explain it a bit clearer to other readers. Many always assume RDBMS are used - which is not always the case. Regards, - Graeme - ___ fpGUI - a cross-platform Free Pascal GUI toolkit http://opensoft.homeip.net/fpgui/ ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] RTTI and Attributes in Delphi 2010
2009/8/16 Paul Ishenin webpi...@mail.ru: Currently RTTI is very limited - using it you can only enumerate published members, learn their types and default values (for properties). Attributes completely eliminates limitations. Explain limitations? Surely you do not want any foreign class to query your private or protected fields? Hence you decide what is viewable by others, making them published. Plus, with the current RTTI you can ever execute published methods etc.. I fail to see what everybody always talk about when they say the RTTI limitations compared to Reflection? An exact example would be very helpful. And the old property mapping to database field doesn't could, because that's a design preference and such mappings are not always appropriate or possible. Regards, - Graeme - ___ fpGUI - a cross-platform Free Pascal GUI toolkit http://opensoft.homeip.net/fpgui/ ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
