Re: [Lazarus] FPReport file names
On 2017-09-13 21:32, Ondrej Pokorny via Lazarus wrote: And I really hate abbreviations since I fail to remember them.:) That is indeed a problem, especially with 600+ tables. eg: What does prefix "I" or "IO" or "IN" mean, when you have 30+ tables starting with the letter "I". Personally I follow your approach kind of. The exception being that I use aliases for table names in big SQL queries, but I tend to use 4 character alias, because 1 character has the same problem as described above (but in a slightly smaller scale). Everybody has their own taste - and it is good so. Otherwise we would all want to marry the same woman:) Good one!!! :-D Regards, Graeme -- ___ Lazarus mailing list Lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] FPReport file names
On Wed, 13 Sep 2017 21:57:50 +0200 Ondrej Pokorny via Lazarus wrote: >[...] > > uses unitdots.unit1, unitdots; > > type > >TPrgBright = unitdots.tbright; > >TPrgColor = unitdots.unit1.tcolor; <-- > > ... > > I don't get it :) > from left to right: is unitdots a namespace? -> yes -> is unit1 a > subnamespace in unitdots? -> no -> is unit1 a file in unitdots > namespace? -> yes -> find tcolor type in unitdots.unit1. Why do you need > to read the identifier backwards? Sadly, there are no subnamespaces in Delphi. For example: uses unitdots.foo.bar, unitdots; t:=unitdots.foo.bla; // foo.bla is defined in unitdots According to your approach: Is unitdots a namespace -> yes -> is foo "subnamespace" -> yes -> find bla in "unitdots.foo" -> does not exist. > + Yes, I have a bug in CodeTools: > > program unitdots.main1; > uses unitdots, unitdots.unit1; > type > TPrgBright = unitdots.tbright; > TPrgColor = unitdots.unit1.tcolor; > TStrange = unitdots.main1.tprgcolor; > var k1: longint; > begin > if unitdots.main1=0 then ; // << compiler error (codetools jump to > "main1: integer;" in unitdots.pas) I fixed that some hours ago. The source name is a special case. > if unitdots.main1.k1=0 then ; // << OK (codetools don't find k1) > if unitdots.j1=0 then ; > if unitdots.unit1.i1=0 then ; > end. > > unit unitdots; > interface > type > tbright = (yes, no); > var > main1: integer; > unit1: integer; > j1: integer; > implementation > end. > > unit unitdots.unit1; > interface > type > tcolor = integer; > var > i1: tcolor; > implementation > end. > > The namespace/unitname takes precedence before an identifier in an > external unit. Yes. > But it still looks to me like everything can be resolved > from left to right - you just need to know the rules. CodeTools don't > know this rule yet. But once they know it, they will resolve it correctly. To be honest, I have to lookup the rules from time to time. I wonder why Delphi did not come up with more intuitive rules. Mattias -- ___ Lazarus mailing list Lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] FPReport file names
On Wed, 13 Sep 2017 22:18:06 +0200 Sven Barth via Lazarus wrote: >[...] > The compiler always searches units in this order: > - as written in uses clause > - all lowercase > - all uppercase > (and this whole block for extensions .pp, .pas and .p) Note that uppercase also uppercase the extension. I recommend to compile with -vt to see the details. > This way on a case insensitive or case preserving (e.g. FAT, NTFS) file > system the correct one is found on the first try and on case sensitive > ones at least the way Lazarus by default stores units (lowercase files, > unitname as-is) on the second try. Hint: Lazarus code completion uses the correct case for unit names even on Windows, which helps using mixed case. Mattias -- ___ Lazarus mailing list Lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] FPReport file names
On 13.09.2017 22:23, Michael Van Canneyt via Lazarus wrote: create table customer ( C_ID INT Primary key, C_FIRSTNAME VARCHAR(30), C_LASTNAME VARCHAR(50) ); CREATE table invoice ( I_ID INT PRIMARY KEY, I_CUSTOMER_FK INT, I_DATE DATE ); ALTER TABLE INVOICE ADD CONSTRAINT R_INVOICE_CUSTOMER FOREIGN KEY (I_CUSTOMER_FK) REFERENCES CUSTOMER(C_ID) ON CASCADE DELETE; 3 "rules" : Prefix is always somehow related to table name. Usually 1 or 2 letters. Occasionaly 3 (if you have close to 600 tables, 2 letters doesn't always cut it) Primary key is always Prefix_ID Foreign key is always Prefix_FOREIGNTABLE_FK The SQL you construct like this is always unambiguous, unless you use the same table twice in a single SQL select there is never any need to prefix the fields with the table name. Interesting approach. I do the opposite: I always (really always, even in simple statements) prefix the fields with the table name (and really the full table name, not an abbreviation/alias) :) With it I get unambiguity as well. And I really hate abbreviations since I fail to remember them. :) Everybody has their own taste - and it is good so. Otherwise we would all want to marry the same woman :) Ondrej -- ___ Lazarus mailing list Lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] FPReport file names
On Wed, 13 Sep 2017, Ondrej Pokorny via Lazarus wrote: On 13.09.2017 20:33, Graeme Geldenhuys via Lazarus wrote: On 2017-09-13 19:17, Michael Van Canneyt via Lazarus wrote: Similarly, every field in a database I create is always uniquely named. So if I ask "where is field TX_ID' I get exactly 1 field, in 1 table. Graeme Geldenhuys can testify that I use this practice even in very big databases. I can confirm that. :) Huh, that's hardcore :) Just curious: how do you define foreign keys? E.g. Customers.ID Invoices.CustomerID Orders.CustomerID create table customer ( C_ID INT Primary key, C_FIRSTNAME VARCHAR(30), C_LASTNAME VARCHAR(50) ); CREATE table invoice ( I_ID INT PRIMARY KEY, I_CUSTOMER_FK INT, I_DATE DATE ); ALTER TABLE INVOICE ADD CONSTRAINT R_INVOICE_CUSTOMER FOREIGN KEY (I_CUSTOMER_FK) REFERENCES CUSTOMER(C_ID) ON CASCADE DELETE; 3 "rules" : Prefix is always somehow related to table name. Usually 1 or 2 letters. Occasionaly 3 (if you have close to 600 tables, 2 letters doesn't always cut it) Primary key is always Prefix_ID Foreign key is always Prefix_FOREIGNTABLE_FK The SQL you construct like this is always unambiguous, unless you use the same table twice in a single SQL select there is never any need to prefix the fields with the table name. Michael. -- ___ Lazarus mailing list Lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] FPReport file names
On 13.09.2017 20:19, Graeme Geldenhuys via Lazarus wrote: > On 2017-09-13 10:30, Michael Van Canneyt via Lazarus wrote: >> When using CamelCase properly, you don't need _ or . at all. > > That would be my preference too. I love CamelCase - though personally I > lowercase my unit names (files), but CamelCase the "unit xxx" line > inside the unit. Me, too :) > Now the next question - how well does FPC (compiler and all utilities > included with FPC) handle camel case units on case sensitive file systems? The compiler always searches units in this order: - as written in uses clause - all lowercase - all uppercase (and this whole block for extensions .pp, .pas and .p) This way on a case insensitive or case preserving (e.g. FAT, NTFS) file system the correct one is found on the first try and on case sensitive ones at least the way Lazarus by default stores units (lowercase files, unitname as-is) on the second try. Regards, Sven -- ___ Lazarus mailing list Lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] FPReport file names
On 13.09.2017 20:24, Graeme Geldenhuys via Lazarus wrote: > On 2017-09-13 14:33, Mattias Gaertner via Lazarus wrote: >> Try "org.|" with the >> Delphi code insight. > > Don't get me started on that again. The Delphi IDE is horribly horribly > broken in comparison to Lazarus IDE. It two weeks of working with Delphi > XE the other week I managed to find 13 bugs in the IDE alone - some > known for years, others unknown. All were confirmed by other Delphi > developers on the Internet. None were fixed in the latest Delphi Seattle > (or whatever the hell the latest version is). Delphi is in a dark place. As if that was any news :P I use Delphi solely to test features I want to implement in FPC ;) Regards, Sven -- ___ Lazarus mailing list Lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] FPReport file names
On 13.09.2017 20:33, Graeme Geldenhuys via Lazarus wrote: On 2017-09-13 19:17, Michael Van Canneyt via Lazarus wrote: Similarly, every field in a database I create is always uniquely named. So if I ask "where is field TX_ID' I get exactly 1 field, in 1 table. Graeme Geldenhuys can testify that I use this practice even in very big databases. I can confirm that. :) Huh, that's hardcore :) Just curious: how do you define foreign keys? E.g. Customers.ID Invoices.CustomerID Orders.CustomerID etc? Ondrej -- ___ Lazarus mailing list Lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] FPReport file names
On 13.09.2017 21:17, Mattias Gaertner via Lazarus wrote: Everything looks like the compiler uses the same algorithm -> it first resolves a then b then c and so on, it doesn't need to go backwards. It's not so simple. See my example for Sven: ... uses unitdots.unit1, unitdots; type TPrgBright = unitdots.tbright; TPrgColor = unitdots.unit1.tcolor; <-- ... I don't get it :) from left to right: is unitdots a namespace? -> yes -> is unit1 a subnamespace in unitdots? -> no -> is unit1 a file in unitdots namespace? -> yes -> find tcolor type in unitdots.unit1. Why do you need to read the identifier backwards? + Yes, I have a bug in CodeTools: program unitdots.main1; uses unitdots, unitdots.unit1; type TPrgBright = unitdots.tbright; TPrgColor = unitdots.unit1.tcolor; TStrange = unitdots.main1.tprgcolor; var k1: longint; begin if unitdots.main1=0 then ; // << compiler error (codetools jump to "main1: integer;" in unitdots.pas) if unitdots.main1.k1=0 then ; // << OK (codetools don't find k1) if unitdots.j1=0 then ; if unitdots.unit1.i1=0 then ; end. unit unitdots; interface type tbright = (yes, no); var main1: integer; unit1: integer; j1: integer; implementation end. unit unitdots.unit1; interface type tcolor = integer; var i1: tcolor; implementation end. The namespace/unitname takes precedence before an identifier in an external unit. But it still looks to me like everything can be resolved from left to right - you just need to know the rules. CodeTools don't know this rule yet. But once they know it, they will resolve it correctly. Ondrej -- ___ Lazarus mailing list Lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] FPReport file names
On Wed, 13 Sep 2017 18:09:40 +0200 Ondrej Pokorny via Lazarus wrote: >[...] > I think you are wrong. Partly. I just didn't tell the whole story. > I didn't study how the compiler resolves the > identifiers internally, but when I developed dotted unit support for > CodeTools I did it so: I register all namespaces and subnamespaces from > known units (for uses clause) and used units (for implementation code) > and resolve the identifiers from left to right - easy and how it's > always been. Yes, and I extended your code even further. > In your example you always know if 'a' is a namespace or an identifier. > The identifier always wins agains a namespace: > > unit ns1.Unit1; > interface > var > A: string; > ns1: Integer; > implementation > initialization > ns1.Unit1.A := 'a'; // << error illegal identifier Correct. But if 'ns1' is part of a namespace, you have to search the namespace with the most dots. > end. > > unit ns1.Unit2; > interface > var > A: string; > ns1: Integer; > implementation > uses > ns1.Unit1; // error: duplicate identifier (bug in CodeTools: they > don't show an error here because they don't test agains identifier in > uses clause- but the compiler is correct) Codetools is usually more tolerant than the compiler. > initialization > ns1 := 1; > end. > > Everything looks like the compiler uses the same algorithm -> it first > resolves a then b then c and so on, it doesn't need to go backwards. It's not so simple. See my example for Sven: ... uses unitdots.unit1, unitdots; type TPrgBright = unitdots.tbright; TPrgColor = unitdots.unit1.tcolor; <-- ... Mattias -- ___ Lazarus mailing list Lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] FPReport file names
Hi, in fact, it is called PascalCase, see https://en.wikipedia.org/wiki/PascalCase V. __ Od: Graeme Geldenhuys via Lazarus Komu: lazarus@lists.lazarus-ide.org Datum: 13.09.2017 20:19 Předmět: Re: [Lazarus] FPReport file names On 2017-09-13 10:30, Michael Van Canneyt via Lazarus wrote: > When using CamelCase properly, you don't need _ or . at all. That would be my preference too. I love CamelCase - though personally I lowercase my unit names (files), but CamelCase the "unit xxx" line inside the unit. Now the next question - how well does FPC (compiler and all utilities included with FPC) handle camel case units on case sensitive file systems? Regards, Graeme -- ___ Lazarus mailing list Lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus <https://lists.lazarus-ide.org/listinfo/lazarus> -- ___ Lazarus mailing list Lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] FPReport file names
On 2017-09-13 10:40, Ondrej Pokorny via Lazarus wrote: Furthermore code tools can handle dotted units (I added the support:) ) and namespaces will be handled as well once FPC supports them. Excellent!!! The development tools are waiting for the underlying compiler to catch up. Only in the open source world. :-D Regards, Graeme -- ___ Lazarus mailing list Lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] FPReport file names
On 2017-09-13 19:17, Michael Van Canneyt via Lazarus wrote: Similarly, every field in a database I create is always uniquely named. So if I ask "where is field TX_ID' I get exactly 1 field, in 1 table. Graeme Geldenhuys can testify that I use this practice even in very big databases. I can confirm that. :) Regards, Graeme -- ___ Lazarus mailing list Lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] FPReport file names
On 2017-09-13 14:33, Mattias Gaertner via Lazarus wrote: Try "org.|" with the Delphi code insight. Don't get me started on that again. The Delphi IDE is horribly horribly broken in comparison to Lazarus IDE. It two weeks of working with Delphi XE the other week I managed to find 13 bugs in the IDE alone - some known for years, others unknown. All were confirmed by other Delphi developers on the Internet. None were fixed in the latest Delphi Seattle (or whatever the hell the latest version is). Delphi is in a dark place. Regards, Graeme -- fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal http://fpgui.sourceforge.net/ My public PGP key: http://tinyurl.com/graeme-pgp -- ___ Lazarus mailing list Lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] FPReport file names
On 2017-09-13 10:30, Michael Van Canneyt via Lazarus wrote: When using CamelCase properly, you don't need _ or . at all. That would be my preference too. I love CamelCase - though personally I lowercase my unit names (files), but CamelCase the "unit xxx" line inside the unit. Now the next question - how well does FPC (compiler and all utilities included with FPC) handle camel case units on case sensitive file systems? Regards, Graeme -- ___ Lazarus mailing list Lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] FPReport file names
On Wed, 13 Sep 2017, Ondrej Pokorny wrote: Of course there can be collisions - if it happens you have to resolve them with explicit namespaces. Making the whole point moot. You can understand namespaces and subnamespaces as a concept for folder structure within code. Of course you can have every single file in root D:\ and use endless CamelCase names: D:\MyCompanyAccounting201705Report1.xls D:\MyCompanyAccounting201705Report2.xls or you can have a decent folder structure: D:\MyCompany\Accounting\2017\05\Report1.xls D:\MyCompany\Accounting\2017\05\Report2.xls It's up to you. The -NSxyz is then similar to "use path" concept. If you see advantages in using folders you just have to admit there are also advantages when using namespaces. The equivalent of uses utils; dcc32 /NSos /NSweb myprogram in your example is the same as saying "find me Report1.xls, search in D:\MyCompany\Accounting\2017\05 and D:\MyCompany\Accounting\2016\05" You will get an ambiguous answer. Which is the whole problem as I was trying to explain. That said, I use directory structure only to find files faster and group them logically. I would still name files in it uniquely. Using your example: D:\MyCompany\Accounting\2017\05\MCA-Report-201705-2.xls I will find the file quickly, and the name will still be unique. (within reasonable bounds) Similarly, every field in a database I create is always uniquely named. So if I ask "where is field TX_ID' I get exactly 1 field, in 1 table. Graeme Geldenhuys can testify that I use this practice even in very big databases. For the same reason: to avoid ambiguity. Michael. -- ___ Lazarus mailing list Lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] FPReport file names
On 13.09.2017 12:28, Michael Van Canneyt wrote: On Wed, 13 Sep 2017, Ondrej Pokorny via Lazarus wrote: On 13.09.2017 12:03, Michael Van Canneyt via Lazarus wrote: On Wed, 13 Sep 2017, Ondrej Pokorny via Lazarus wrote: The benefit of writing fpreport.exporthtml versus fpreportexporthtml is zero. You forgot one thing: third-party libraries. E.g. your fpReport could use the "fprep" namespace. In the fpReport package you then define to use the fprep namespace - it means you can use units in fpReport without the "fprep" namespace - and without any collisions. This is demonstrably not correct. It is *Only* correct if there are not 2 namespaces with the same unit in your project. See my example program, it demonstrates exactly that. You didn't understand me. I was talking about a 3rd party library package and not about your/my project. Yes. And the same is true for this package. You can play this game forever... Of course there can be collisions - if it happens you have to resolve them with explicit namespaces. Making the whole point moot. You can understand namespaces and subnamespaces as a concept for folder structure within code. Of course you can have every single file in root D:\ and use endless CamelCase names: D:\MyCompanyAccounting201705Report1.xls D:\MyCompanyAccounting201705Report2.xls or you can have a decent folder structure: D:\MyCompany\Accounting\2017\05\Report1.xls D:\MyCompany\Accounting\2017\05\Report2.xls It's up to you. The -NSxyz is then similar to "use path" concept. If you see advantages in using folders you just have to admit there are also advantages when using namespaces. Ondrej -- ___ Lazarus mailing list Lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] FPReport file names
On 13.09.2017 15:33, Mattias Gaertner via Lazarus wrote: Also were is there an ambiguity anyway (given all units are used with their full name)? The compiler reads (in my above example) the token sequence ID Point ID and thus can find the unit without any backtracking just as for ordinary methods. Even once the default namespace option is added that won't change as the compiler will simply test all provided namespaces as prefixes and then the name as is. It's just a longer list of names than usually to test for. Let's say you have 'a.b.c.d'. Before namespaces the compiler could simply resolve a, then b, then c and finally d. With namespaces the compiler has to read the full 'a.b.c.d', then search for a.b.c, then a.b, then a and then resolve the rest as before. I think you are wrong. I didn't study how the compiler resolves the identifiers internally, but when I developed dotted unit support for CodeTools I did it so: I register all namespaces and subnamespaces from known units (for uses clause) and used units (for implementation code) and resolve the identifiers from left to right - easy and how it's always been. In your example you always know if 'a' is a namespace or an identifier. The identifier always wins agains a namespace: unit ns1.Unit1; interface var A: string; ns1: Integer; implementation initialization ns1.Unit1.A := 'a'; // << error illegal identifier end. unit ns1.Unit2; interface var A: string; ns1: Integer; implementation uses ns1.Unit1; // error: duplicate identifier (bug in CodeTools: they don't show an error here because they don't test agains identifier in uses clause- but the compiler is correct) initialization ns1 := 1; end. Everything looks like the compiler uses the same algorithm -> it first resolves a then b then c and so on, it doesn't need to go backwards. Ondrej -- ___ Lazarus mailing list Lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] FPReport file names
On Wed, 13 Sep 2017, Graeme Geldenhuys via Lazarus wrote: On 2017-09-13 09:44, Michael Van Canneyt via Lazarus wrote: As long as there are no command-line switch and directive for setting namespaces, they are completely useless. Like I said, FPC still needs a bit more work before namespaces become more useful (or workable like Delphi intended). > And even with the command-line switch, the 'namespaces stop unit name > conflicts'argument is of course complete nonsense. It can greatly reduce conflicts. So fpreportexporthtml.pp would become: fpc.fpreport.export.html.pp Please take a good look at what you are writing. You are _seriously_ telling me that the chance of conflicts is "greatly reduced" when I use fpreport.export.html compared to when I use fpreportexporthtml ? Either the world or me has lost its marbles. I'm pretty sure it is not me. At last count, I still had them all. (But then that would be normal if I was going crazy :)) I will not argue about readability; that's a matter of taste: I much prefer FPReportExportHTML over fpreport_export_html or fpreport.export.html. Michael. -- ___ Lazarus mailing list Lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] FPReport file names
On 2017-09-13 09:44, Michael Van Canneyt via Lazarus wrote: As long as there are no command-line switch and directive for setting namespaces, they are completely useless. Like I said, FPC still needs a bit more work before namespaces become more useful (or workable like Delphi intended). > And even with the command-line switch, the 'namespaces stop unit name > conflicts'argument is of course complete nonsense. It can greatly reduce conflicts. I would follow the Java namespace convention, and add a company name or organization as part of the namespace. So fpreportexporthtml.pp would become: fpc.fpreport.export.html.pp Granted that is a long unit name, but so is the original, and at least the dotted name reads much easier. Human minds don't read all lowercase or all uppercase combined words very easily - just look at MSEide's code. Only Martin likes that (and maybe you). ;-) Anyway, I would suggest all FPC units are prefixed with the "fpc." namespace. An example where namespaces do work well, is in tiOPF's "tiopf3" branch. The same unit names exist in VCL and FMX. Using namespaces as part of the target platform you want, it automatically helps resolve which unit you are referring to. So yes, we can show pros and cons to namespaces. Regards, Graeme -- fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal http://fpgui.sourceforge.net/ My public PGP key: http://tinyurl.com/graeme-pgp -- ___ Lazarus mailing list Lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] FPReport file names
Am 13.09.2017 15:33 schrieb "Mattias Gaertner via Lazarus" < lazarus@lists.lazarus-ide.org>: > > On Wed, 13 Sep 2017 14:38:55 +0200 > Sven Barth via Lazarus wrote: > > >[...] > > I'm not talking about ambiguity, I'm talking about aesthetics: FooBar.Blubb > > is easier to discern visually than FooBarBlubb. > > Well, aesthetics often goes together with "used to". > I'm used to a point separates a sub identifier. > The Delphi namespace concept breaks this rule. E.g. in a namespace > "org.fpc" the dot is part of the identifier. Try "org.|" with the > Delphi code insight. It does not show all possibilities. Lazarus code > completion works better here. We all know that Delphi isn't the best example of an IDE out there :P > > Also were is there an ambiguity anyway (given all units are used with their > > full name)? The compiler reads (in my above example) the token sequence ID > > Point ID and thus can find the unit without any backtracking just as for > > ordinary methods. Even once the default namespace option is added that > > won't change as the compiler will simply test all provided namespaces as > > prefixes and then the name as is. It's just a longer list of names than > > usually to test for. > > Let's say you have 'a.b.c.d'. Before namespaces the compiler could > simply resolve a, then b, then c and finally d. > With namespaces the compiler has to read the full 'a.b.c.d', > then search for a.b.c, then a.b, then a and then resolve the rest as > before. Ah, using the identifier inside code. Okay I grant you that one regarding ambiguity... Regards, Sven -- ___ Lazarus mailing list Lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] FPReport file names
On Wed, 13 Sep 2017 14:38:55 +0200 Sven Barth via Lazarus wrote: >[...] > I'm not talking about ambiguity, I'm talking about aesthetics: FooBar.Blubb > is easier to discern visually than FooBarBlubb. Well, aesthetics often goes together with "used to". I'm used to a point separates a sub identifier. The Delphi namespace concept breaks this rule. E.g. in a namespace "org.fpc" the dot is part of the identifier. Try "org.|" with the Delphi code insight. It does not show all possibilities. Lazarus code completion works better here. > Also were is there an ambiguity anyway (given all units are used with their > full name)? The compiler reads (in my above example) the token sequence ID > Point ID and thus can find the unit without any backtracking just as for > ordinary methods. Even once the default namespace option is added that > won't change as the compiler will simply test all provided namespaces as > prefixes and then the name as is. It's just a longer list of names than > usually to test for. Let's say you have 'a.b.c.d'. Before namespaces the compiler could simply resolve a, then b, then c and finally d. With namespaces the compiler has to read the full 'a.b.c.d', then search for a.b.c, then a.b, then a and then resolve the rest as before. For example: program unitdots.main1: uses unitdots.unit1, unitdots; type TPrgBright = unitdots.tbright; TPrgColor = unitdots.unit1.tcolor; TStrange = unitdots.main1.tprgcolor; var k1: longint; begin if unitdots.main1.k1=0 then ; if unitdots.j1=0 then ; if unitdots.unit1.i1=0 then ; Mattias -- ___ Lazarus mailing list Lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] FPReport file names
Am 13.09.2017 11:59 schrieb "Mattias Gaertner via Lazarus" < lazarus@lists.lazarus-ide.org>: > > On Wed, 13 Sep 2017 11:40:23 +0200 > Mattias Gaertner via Lazarus wrote: > > > On Wed, 13 Sep 2017 11:19:58 +0200 > > Sven Barth via Lazarus wrote: > > > > >[...] > > > The "." allows for a nicer disambiguation between what's the prefix and > > > what's the remainder. Granted, that can be done with "_" as well, but in my > > > personal opinion a "." simply looks nicer. :) > > > > I don't get why disambiguity is "nicer". The compiler has to > > backstep and try all combinations to find out what a.b.c means. > > I meant ambiguity. ;) I'm not talking about ambiguity, I'm talking about aesthetics: FooBar.Blubb is easier to discern visually than FooBarBlubb. Also were is there an ambiguity anyway (given all units are used with their full name)? The compiler reads (in my above example) the token sequence ID Point ID and thus can find the unit without any backtracking just as for ordinary methods. Even once the default namespace option is added that won't change as the compiler will simply test all provided namespaces as prefixes and then the name as is. It's just a longer list of names than usually to test for. Regards, Sven -- ___ Lazarus mailing list Lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] FPReport file names
On Wed, 13 Sep 2017, Ondrej Pokorny via Lazarus wrote: On 13.09.2017 12:03, Michael Van Canneyt via Lazarus wrote: On Wed, 13 Sep 2017, Ondrej Pokorny via Lazarus wrote: The benefit of writing fpreport.exporthtml versus fpreportexporthtml is zero. You forgot one thing: third-party libraries. E.g. your fpReport could use the "fprep" namespace. In the fpReport package you then define to use the fprep namespace - it means you can use units in fpReport without the "fprep" namespace - and without any collisions. This is demonstrably not correct. It is *Only* correct if there are not 2 namespaces with the same unit in your project. See my example program, it demonstrates exactly that. You didn't understand me. I was talking about a 3rd party library package and not about your/my project. Yes. And the same is true for this package. Of course there can be collisions - if it happens you have to resolve them with explicit namespaces. Making the whole point moot. Michael. -- ___ Lazarus mailing list Lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] FPReport file names
On 13.09.2017 12:03, Michael Van Canneyt via Lazarus wrote: On Wed, 13 Sep 2017, Ondrej Pokorny via Lazarus wrote: The benefit of writing fpreport.exporthtml versus fpreportexporthtml is zero. You forgot one thing: third-party libraries. E.g. your fpReport could use the "fprep" namespace. In the fpReport package you then define to use the fprep namespace - it means you can use units in fpReport without the "fprep" namespace - and without any collisions. This is demonstrably not correct. It is *Only* correct if there are not 2 namespaces with the same unit in your project. See my example program, it demonstrates exactly that. You didn't understand me. I was talking about a 3rd party library package and not about your/my project. Of course there can be collisions - if it happens you have to resolve them with explicit namespaces. Ondrej -- ___ Lazarus mailing list Lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] FPReport file names
On Wed, 13 Sep 2017, Mattias Gaertner wrote: On Wed, 13 Sep 2017 11:28:55 +0200 (CEST) Michael Van Canneyt wrote: [...] The benefit of writing fpreport.exporthtml versus fpreportexporthtml is zero. It's a little bit better than zero. For example shorter uses clause. Without using a switch to set namespaces ? Please Explain ? Namespaces without the switch are pretty useless. I thought you were talking about namespaces as in Delphi. Sorry for the misunderstanding. They are one and the same. [...] Did you add "uses utils"? Yes, obviously. Here is the test program: I see now that your point was the order of namespaces. Which is an issue with unit paths as well. But with namespaces you can always pass the whole unit name, while with unit paths you cannot. So I'm not sure why the order is an argument against namespaces. Because, as I demonstrated, the order issue forces you to disambiguate the unit names anyway. Writing "uses utils;" is ambiguous if you are using 2 namespaces which both have a "utils" unit, and you use both of them somewhere in your project. We are agreed on that, I hope. So, to avoid this, you must write "uses web.utils" and "uses os.utils" (using my example). So, if you write a class library (using a namespace) with many units, you don't know in what environment it will be used, and what namespaces the end user will use on the command line (or maybe none). So, you must make sure all your code is unambiguous, i.e. write "namespace.unitname" everywhere. The same is true for the end-user. (see my demonstration program). So if you must disambiguate anyway (i.e. write web.utils). the whole point of using a namespace ("shorter names") becomes moot. I am not trying to dissuade anyone from using namespaces. I am trying to debunk a myth, namely that it will avoid unit name clashes. It does not, and in certain circumstances (using /NS switch) makes the problem only worse. The end point - what got all this started - is that whether you use fpreportutils.pp or fpreport.utils.pp is a matter of personal preference only. Using the latter does not avoid the possibility of name clashes. Michael. -- ___ Lazarus mailing list Lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] FPReport file names
On Wed, 13 Sep 2017, Ondrej Pokorny via Lazarus wrote: The benefit of writing fpreport.exporthtml versus fpreportexporthtml is zero. You forgot one thing: third-party libraries. E.g. your fpReport could use the "fprep" namespace. In the fpReport package you then define to use the fprep namespace - it means you can use units in fpReport without the "fprep" namespace - and without any collisions. This is demonstrably not correct. It is *Only* correct if there are not 2 namespaces with the same unit in your project. See my example program, it demonstrates exactly that. Michael. -- ___ Lazarus mailing list Lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] FPReport file names
On Wed, 13 Sep 2017 11:40:23 +0200 Mattias Gaertner via Lazarus wrote: > On Wed, 13 Sep 2017 11:19:58 +0200 > Sven Barth via Lazarus wrote: > > >[...] > > The "." allows for a nicer disambiguation between what's the prefix and > > what's the remainder. Granted, that can be done with "_" as well, but in my > > personal opinion a "." simply looks nicer. :) > > I don't get why disambiguity is "nicer". The compiler has to > backstep and try all combinations to find out what a.b.c means. I meant ambiguity. ;) Mattias -- ___ Lazarus mailing list Lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] FPReport file names
On 13.09.2017 10:44, Michael Van Canneyt via Lazarus wrote: On Wed, 13 Sep 2017, Graeme Geldenhuys via Lazarus wrote: On 2017-09-12 19:01, Alexey via Lazarus wrote: It is new. Please rename (it's easy for new component) all files: usually its good with one prefix. E.g. fprep_*.*. hahaha... I had the units like that, using underscores. eg: fpreport_export_aggpas.pas, fpreport_export_fpimage.pas etc. Michael didn't like it, so it got renamed before it went into FPC Trunk. :) The LCL related units could be prefixed though, as Michael mentioned. They should be, since some of the names used in the designer are indeed too generic. Then again, maybe it's time FPC starts making use of namespaces and dotted unit names? Just a thought. In Delphi it is actually pretty useful and also stops unit name conflicts. FPC does need a bit more work though to fully support namespaces - at least the way Delphi uses it. As long as there are no command-line switch and directive for setting namespaces, they are completely useless. And even with them, the benefit is doubtful. The benefit of writing fpreport.exporthtml versus fpreportexporthtml is zero. You forgot one thing: third-party libraries. E.g. your fpReport could use the "fprep" namespace. In the fpReport package you then define to use the fprep namespace - it means you can use units in fpReport without the "fprep" namespace - and without any collisions. In the main application you have the choice if you want to add the fprep namespace and can use fpReport units without the namespace or not. Collisions have to be resolved with the namespace anyway - but this is no really drawback. Furthermore code tools can handle dotted units (I added the support :) ) and namespaces will be handled as well once FPC supports them. So yes, namespaces are good :) - or at least they are no harm. It's your decision not to use them - they won't break anything. Ondrej -- ___ Lazarus mailing list Lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] FPReport file names
On Wed, 13 Sep 2017 11:19:58 +0200 Sven Barth via Lazarus wrote: >[...] > The "." allows for a nicer disambiguation between what's the prefix and > what's the remainder. Granted, that can be done with "_" as well, but in my > personal opinion a "." simply looks nicer. :) I don't get why disambiguity is "nicer". The compiler has to backstep and try all combinations to find out what a.b.c means. Mattias -- ___ Lazarus mailing list Lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] FPReport file names
On 13/09/17 10:19, Sven Barth via Lazarus wrote: > Am 13.09.2017 10:45 schrieb "Michael Van Canneyt via Lazarus" >> The benefit of writing fpreport.exporthtml versus >> fpreportexporthtml is zero. >> > > The "." allows for a nicer disambiguation between what's the prefix > and what's the remainder. Granted, that can be done with "_" as well, > but in my personal opinion a "." simply looks nicer. :) > > Regards, Sven From POV of an 'ordinary user' I came to say the same thing > fpreportexporthtml > fpreport.exporthtml is exactly only 1 character longer but the separator (. or _) makes a lot of difference... -L. -- ___ Lazarus mailing list Lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] FPReport file names
On Wed, 13 Sep 2017, Sven Barth via Lazarus wrote: As long as there are no command-line switch and directive for setting namespaces, they are completely useless. And even with them, the benefit is doubtful. The benefit of writing fpreport.exporthtml versus fpreportexporthtml is zero. The "." allows for a nicer disambiguation between what's the prefix and what's the remainder. Oh please... Granted, that can be done with "_" as well, but in my personal opinion a "." simply looks nicer. :) It's an extra character. When using CamelCase properly, you don't need _ or . at all. Michael. -- ___ Lazarus mailing list Lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] FPReport file names
On Wed, 13 Sep 2017, Mattias Gaertner via Lazarus wrote: On Wed, 13 Sep 2017 10:44:23 +0200 (CEST) Michael Van Canneyt via Lazarus wrote: [...] As long as there are no command-line switch and directive for setting namespaces, they are completely useless. And even with them, the benefit is doubtful. The benefit of writing fpreport.exporthtml versus fpreportexporthtml is zero. It's a little bit better than zero. For example shorter uses clause. Without using a switch to set namespaces ? Please Explain ? os.utils.pas(14) testns.dpr(6) Error: E2003 Undeclared identifier: 'webfunction' testns.dpr(7) webfunction is in the web.utils.pas unit. Did you add "uses utils"? Yes, obviously. Here is the test program: program testns; uses utils; begin writeln(webfunction); end. unit web.utils; interface function webfunction : string; implementation function webfunction : string; begin Result:='web'; end; end. unit os.utils; interface function osfunction : string; implementation function osfunction : string; begin Result:='os'; end; end. There is no switch to use "web.*" like in Java. In Delphi there is: /NSweb. But as soon as you use 2 namespaces (/NSos /NSWeb), you are stuck. As you see from the output I posted, it compiles first os.utils and uses that to satisfy the "uses utils;". To be complete: it depends on the order of the NS switches, if you reverse the order, it will work - but that doesn't help if you have a big project which has many units using utils from one or the other namespace. The first one wins. So, to disambiguate, that forces me to write uses web.utils; "uses utils" should be enough. As I demonstrated: it clearly is not. I carefully tested everything before posting my remark. Michael. -- ___ Lazarus mailing list Lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] FPReport file names
On 09/13/2017 05:13 AM, Mattias Gaertner via Lazarus wrote: On Wed, 13 Sep 2017 10:44:23 +0200 (CEST) Michael Van Canneyt via Lazarus wrote: [...] I tested in Delphi: c:\Temp>dcc32 /NSos /NSweb testns.dpr Embarcadero Delphi for Win32 compiler version 30.0 Copyright (c) 1983,2015 Embarcadero Technologies, Inc. os.utils.pas(14) testns.dpr(6) Error: E2003 Undeclared identifier: 'webfunction' testns.dpr(7) webfunction is in the web.utils.pas unit. Did you add "uses utils"? ummm... On 09/13/2017 04:44 AM, Michael Van Canneyt via Lazarus wrote: [...] > Imagine: > > web.utils.pas > os.utils.pas > > and in my project I have (I love to use the namespace param) > > *uses utils;* > > And now I compile with a (hypothetical) /NSweb /NSos -> problem. ;) -- NOTE: No off-list assistance is given without prior approval. *Please keep mailing list traffic on the list unless* *a signed and pre-paid contract is in effect with us.* -- ___ Lazarus mailing list Lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] FPReport file names
Am 13.09.2017 10:45 schrieb "Michael Van Canneyt via Lazarus" < lazarus@lists.lazarus-ide.org>: > > > > On Wed, 13 Sep 2017, Graeme Geldenhuys via Lazarus wrote: > >> On 2017-09-12 19:01, Alexey via Lazarus wrote: >>> >>> It is new. Please rename (it's easy for new component) all files: >>> usually its good with one prefix. E.g. fprep_*.*. >> >> >> hahaha... I had the units like that, using underscores. eg: fpreport_export_aggpas.pas, fpreport_export_fpimage.pas etc. Michael didn't like it, so it got renamed before it went into FPC Trunk. :) >> >> The LCL related units could be prefixed though, as Michael mentioned. > > > They should be, since some of the names used in the designer are indeed too > generic. > > >> Then again, maybe it's time FPC starts making use of namespaces and dotted unit names? Just a thought. In Delphi it is actually pretty useful and also stops unit name conflicts. FPC does need a bit more work though to fully support namespaces - at least the way Delphi uses it. > > > As long as there are no command-line switch and directive for setting namespaces, they are completely useless. And even with them, the benefit is > doubtful. > > The benefit of writing fpreport.exporthtml versus fpreportexporthtml is zero. > The "." allows for a nicer disambiguation between what's the prefix and what's the remainder. Granted, that can be done with "_" as well, but in my personal opinion a "." simply looks nicer. :) Regards, Sven -- ___ Lazarus mailing list Lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] FPReport file names
On Wed, 13 Sep 2017 10:44:23 +0200 (CEST) Michael Van Canneyt via Lazarus wrote: >[...] > As long as there are no command-line switch and directive for setting > namespaces, they are completely useless. And even with them, the benefit is > doubtful. > > The benefit of writing fpreport.exporthtml versus fpreportexporthtml is zero. It's a little bit better than zero. For example shorter uses clause. > And even with the command-line switch, the 'namespaces stop unit name > conflicts' > argument is of course complete nonsense. True. >[...] > I tested in Delphi: > > c:\Temp>dcc32 /NSos /NSweb testns.dpr > Embarcadero Delphi for Win32 compiler version 30.0 > Copyright (c) 1983,2015 Embarcadero Technologies, Inc. > os.utils.pas(14) > testns.dpr(6) Error: E2003 Undeclared identifier: 'webfunction' > testns.dpr(7) > > webfunction is in the web.utils.pas unit. Did you add "uses utils"? There is no switch to use "web.*" like in Java. > So, to disambiguate, that forces me to write > > uses web.utils; "uses utils" should be enough. Mattias -- ___ Lazarus mailing list Lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] FPReport file names
On Wed, 13 Sep 2017, Graeme Geldenhuys via Lazarus wrote: On 2017-09-12 19:01, Alexey via Lazarus wrote: It is new. Please rename (it's easy for new component) all files: usually its good with one prefix. E.g. fprep_*.*. hahaha... I had the units like that, using underscores. eg: fpreport_export_aggpas.pas, fpreport_export_fpimage.pas etc. Michael didn't like it, so it got renamed before it went into FPC Trunk. :) The LCL related units could be prefixed though, as Michael mentioned. They should be, since some of the names used in the designer are indeed too generic. Then again, maybe it's time FPC starts making use of namespaces and dotted unit names? Just a thought. In Delphi it is actually pretty useful and also stops unit name conflicts. FPC does need a bit more work though to fully support namespaces - at least the way Delphi uses it. As long as there are no command-line switch and directive for setting namespaces, they are completely useless. And even with them, the benefit is doubtful. The benefit of writing fpreport.exporthtml versus fpreportexporthtml is zero. And even with the command-line switch, the 'namespaces stop unit name conflicts' argument is of course complete nonsense. Whoever originally tossed that argument into the world needs to be ridiculed for either being stupid or not thinking his argument through. because a) I could equally easy decide to use the same namespace as someone else. (Yes, I have a notoriously bad character) b) If you use the namespace param too much, you are in trouble anyway. Imagine: web.utils.pas os.utils.pas and in my project I have (I love to use the namespace param) uses utils; And now I compile with a (hypothetical) /NSweb /NSos -> problem. I tested in Delphi: c:\Temp>dcc32 /NSos /NSweb testns.dpr Embarcadero Delphi for Win32 compiler version 30.0 Copyright (c) 1983,2015 Embarcadero Technologies, Inc. os.utils.pas(14) testns.dpr(6) Error: E2003 Undeclared identifier: 'webfunction' testns.dpr(7) webfunction is in the web.utils.pas unit. So, to disambiguate, that forces me to write uses web.utils; in which case I can just as well have written uses webutils; So we're back to square 1. Michael. -- ___ Lazarus mailing list Lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] FPReport file names
On 2017-09-12 19:01, Alexey via Lazarus wrote: It is new. Please rename (it's easy for new component) all files: usually its good with one prefix. E.g. fprep_*.*. hahaha... I had the units like that, using underscores. eg: fpreport_export_aggpas.pas, fpreport_export_fpimage.pas etc. Michael didn't like it, so it got renamed before it went into FPC Trunk. :) The LCL related units could be prefixed though, as Michael mentioned. Then again, maybe it's time FPC starts making use of namespaces and dotted unit names? Just a thought. In Delphi it is actually pretty useful and also stops unit name conflicts. FPC does need a bit more work though to fully support namespaces - at least the way Delphi uses it. Regards, Graeme -- fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal http://fpgui.sourceforge.net/ My public PGP key: http://tinyurl.com/graeme-pgp -- ___ Lazarus mailing list Lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] FPReport file names
On Tue, 12 Sep 2017, Alexey via Lazarus wrote: On 12.09.2017 21:25, Michael Van Canneyt via Lazarus wrote: Why would people see filename conflicts ? None of these files exist yet. because files like dlginputcombo.pp, fradbfdata.*, frmresizeelements.* may exist in BIG app. The ones without prefix can indeed be prefixed. Michael. -- ___ Lazarus mailing list Lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] FPReport file names
On 12.09.2017 21:25, Michael Van Canneyt via Lazarus wrote: Why would people see filename conflicts ? None of these files exist yet. because files like dlginputcombo.pp, fradbfdata.*, frmresizeelements.* may exist in BIG app. -- Regards, Alexey -- ___ Lazarus mailing list Lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] FPReport file names
On Tue, 12 Sep 2017, Alexey via Lazarus wrote: Definitely not. It is good to do (some users will see filename conflicts in big apps). no big apps ready on FPRep yet. Why would people see filename conflicts ? None of these files exist yet. And there are already apps in production using fpreport. Michael. -- ___ Lazarus mailing list Lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] FPReport file names
>Definitely not. It is good to do (some users will see filename conflicts in big apps). no big apps ready on FPRep yet. -- Regards, Alexey -- ___ Lazarus mailing list Lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] FPReport file names
On Tue, 12 Sep 2017, Alexey via Lazarus wrote: Hi It is new. Please rename (it's easy for new component) all files: usually its good with one prefix. E.g. fprep_*.*. Definitely not. Michael. -- ___ Lazarus mailing list Lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus