Hi

It is new. Please rename (it's easy for new component) all files: usually its good with one prefix. E.g. fprep_*.*.

And form resources: 18 LFM files, 29 pas files. Pls rename with prefix too, to avoid LFM conflicts.

Alexey 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.

Definitely not.

It is good to do (some users will see filename conflicts in big apps). no big apps ready on FPRep yet.

Alexey 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.

Michael Van Canneyt 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.

Alexey 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

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.

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.

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

Am 13.09.2017 10:45 schrieb "Michael Van Canneyt via Lazarus" <

fpreport_export_aggpas.pas, fpreport_export_fpimage.pas etc. Michael didn't like it, so it got renamed before it went into FPC Trunk. :)

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus-ide.org/pipermail/lazarus/attachments/20170913/274ee63d/attachment.html>

ummm...

On 09/13/2017 04:44 AM, Michael Van Canneyt via Lazarus wrote: [...]

;)

Without using a switch to set namespaces ? Please Explain ?

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.

As I demonstrated: it clearly is not.

I carefully tested everything before posting my remark.

Michael.

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 .

fpreportexporthtml fpreport.exporthtml

is exactly only 1 character longer but the separator (. or _) makes a lot of difference...

-L.

[...] 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

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus-ide.org/pipermail/lazarus/attachments/20170913/d5719f74/attachment-0001.html>

I meant ambiguity. ;)

Mattias

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.

They are one and the same.

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.

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

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.

Am 13.09.2017 11:59 schrieb "Mattias Gaertner via Lazarus" <

and

> > what's the remainder. Granted, that can be done with "_" as well, but

in my

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus-ide.org/pipermail/lazarus/attachments/20170913/b1f35b9e/attachment.html>

[...] 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.

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

Am 13.09.2017 15:33 schrieb "Mattias Gaertner via Lazarus" <

FooBar.Blubb

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

Ah, using the identifier inside code. Okay I grant you that one regarding ambiguity...

Regards,
Sven
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus-ide.org/pipermail/lazarus/attachments/20170913/0d232e75/attachment.html>

Michael Van Canneyt 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

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.

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

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

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.

Michael Van Canneyt wrote

When using CamelCase properly, you don't need _ or 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

Mattias Gaertner 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

Michael Van Canneyt 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

Ondrej Pokorny 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

Hi,
 
in fact, it is called PascalCase, see https://en.wikipedia.org/wiki/PascalCase  
V.
______________________________________________________________

Michael Van Canneyt wrote

When using CamelCase properly, you don't need _ or 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

[...] I think you are wrong.

Partly. I just didn't tell the whole story.

Yes, and I extended your code even further.

Correct. But if 'ns1' is part of a namespace, you have to search the namespace with the most dots.

Codetools is usually more tolerant than the compiler.

It's not so simple. See my example for Sven:
...
uses unitdots.unit1, unitdots;
type

  TPrgBright = unitdots.tbright;
  TPrgColor = unitdots.unit1.tcolor; <--

...

Mattias

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

Huh, that's hardcore :)

Just curious: how do you define foreign keys? E.g. Customers.ID
Invoices.CustomerID
Orders.CustomerID

etc?

Ondrej

As if that was any news :P
I use Delphi solely to test features I want to implement in FPC ;)

Regards,
Sven

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

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.

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

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

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.

I fixed that some hours ago. The source name is a special case.

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

Ondrej Pokorny 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