Re: [Lazarus] FPReport file names

[Mattias Gaertner via Lazarus]

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

[Mattias Gaertner via Lazarus]

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

[Michael Van Canneyt via Lazarus]

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

[Sven Barth via Lazarus]

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

[Sven Barth via Lazarus]

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

[Ondrej Pokorny via Lazarus]

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

[Mattias Gaertner via Lazarus]

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

[Vojtěch Čihák via Lazarus]

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 


-- 
___
Lazarus mailing list
Lazarus@lists.lazarus-ide.org
https://lists.lazarus-ide.org/listinfo/lazarus

Re: [Lazarus] FPReport file names

[Graeme Geldenhuys via Lazarus]

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

[Graeme Geldenhuys via Lazarus]

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

[Graeme Geldenhuys via Lazarus]

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

[Graeme Geldenhuys via Lazarus]

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

[Michael Van Canneyt via Lazarus]

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

[Ondrej Pokorny via Lazarus]

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

[Graeme Geldenhuys via Lazarus]

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

[Mattias Gaertner via Lazarus]

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

[Sven Barth via Lazarus]

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] LazReport - Issues 26971 and 30466

[zeljko via Lazarus]

On 09/13/2017 10:51 AM, Gabor Boros via Lazarus wrote:

Hi All,

https://bugs.freepascal.org/view.php?id=26971

~3 years later. Any idea?


No

zeljko
--
___
Lazarus mailing list
Lazarus@lists.lazarus-ide.org
https://lists.lazarus-ide.org/listinfo/lazarus

Re: [Lazarus] FPReport file names

[Michael Van Canneyt via Lazarus]

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

[Ondrej Pokorny via Lazarus]

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

[Michael Van Canneyt via Lazarus]

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

[Michael Van Canneyt via Lazarus]

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

[Mattias Gaertner via Lazarus]

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

[Ondrej Pokorny via Lazarus]

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

[Mattias Gaertner via Lazarus]

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

[el es via Lazarus]

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

[Michael Van Canneyt via Lazarus]

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

[Michael Van Canneyt via Lazarus]

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

[wkitty42--- via Lazarus]

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

[Sven Barth via Lazarus]

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

[Mattias Gaertner via Lazarus]

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

[Lazarus] LazReport - Issues 26971 and 30466

[Gabor Boros via Lazarus]

Hi All,

https://bugs.freepascal.org/view.php?id=26971

~3 years later. Any idea?

https://bugs.freepascal.org/view.php?id=30466

The KeepChild feature is very important from my POV. Please review the 
patch. (I have not tried yet.)


Gabor
--
___
Lazarus mailing list
Lazarus@lists.lazarus-ide.org
https://lists.lazarus-ide.org/listinfo/lazarus

Re: [Lazarus] FPReport file names

[Michael Van Canneyt via Lazarus]

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

[Graeme Geldenhuys via Lazarus]

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