[Lazarus] FPReport file names

[Ondrej Pokorny]

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

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