It would seem that the Lazarus IDE integrated documentation editor fails to work with units which use dotted names. For example:

unit MyCompany.Utilities.Text;

Can someone verify this for me? I am preparing some OSS pascal packages (a cross platforming gaming library) which use the above pattern for unit organization and was hoping to start writing documentation.

Also, same thing applies to fpdoc. Does it support namespace dotted units? -------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20130413/b256e03c/attachment.html>

I'm curious: why do you use dots instead of for example underscores?

Also, same thing applies to fpdoc. Does it support namespace dotted units?

Mattias

Because in theory you should get code insight when you type Identified(dot). From a style perspective I also tend to avoid underscores in my own identifiers. I reserve underscores for methods you normally shouldn't call (_AddRef), or for imported C code (MAX_PATH, type_).

Also, I am sure you know dotted unit namespaces are an addition to Free Pascal. They are familiar to C#/Java people, and probably look better (style-wise) to them. If they see dotted unit namespaces in some Free Pascal demos they might be more be tempted to give Free Pascal a look rather than running away (especially if the first thing they see when looking at a Free Pascal example is a list of large identifiers with 2 or more underscores each).
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20130413/faf967d4/attachment-0001.html>

I tested on on another computer with a different OS (Windows 7) and replicated the problem. I filled out 3 bug reports for issue numbers 0024269, 0024270, and 0024271. One issue is related to a copy and paste problem with the integrated Lazarus documentation editor window. -------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20130413/3aeee2cd/attachment.html>

In short words: aesthetic reasons and to please people from other languages. Right?

What example has a large list of identifiers with many underscores? Why is that better than a large list with many dots?

Mattias

Why shouldn't you? Also in difference to underscores each part of the dotted unit name will be a unique symbol. E.g. for a unit name like System.Collection.Generics all three parts will be a symbol so you can't use them in your code (can be considered both an advantage and a disadvantage).

Also FPC will in the future also provide units with dotted unitnames to increase compatibility with Delphi XE2 and newer.

Regards,
Sven

Normally I don't reply to a technical discussion when a question about a possible bug is posed back with (channels inner nerd) "Why would you ever want to do that?"... followed up attempts to chastise. But I'll give you some honest answers.

In short words: aesthetic reasons and to please people from other

languages. Right?

No.

What example has a large list of identifiers with many underscores? Why is that better than a large list with many dots?

It depends.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20130414/4f83b118/attachment.html>

Thanks. You are one of the few people who give some arguments beside aesthetic reasons.

Also FPC will in the future also provide units with dotted unitnames to increase compatibility with Delphi XE2 and newer.

Can you explain or give some link about the rules for dotted unit names FPC will implement?

Mattias

It's still a bit in flux and currently only discussed on the core list, but basically the idea is to use Delphi XE2's unit naming scheme at least for the base units (e.g. System.SysUtils.pp or System.Classes.pp) and make these units use String=UnicodeString while the non dotted units (to stay with the example SysUtils.pp and Classes.pp) keep String=AnsiString for backwards compatiblity.
I hope that more information can be provided after the compiler Hackathon from 30th May to 2nd June where some of use will try to implement this scheme (and also extend the compiler with a few things for this).

Regards,
Sven

Normally I don't reply to a technical discussion when a question about a possible bug is posed back with (channels inner nerd) "Why would you ever want to do that?"... followed up attempts to chastise. But I'll give you some honest answers.

The dotted unit name concept is not a simple change. It heavily effects the scope rules and resolving mechanism.
There are many other todos, so you have to convince developers, that this feature has no simple workaround and has priority.

But maybe you don't need the full dotted unit name concept. Then maybe some half implementations are enough.

Mattias

Yes, afair this basic idea was already mentioned on some other list.

I meant, can you give me the rules for the dotted unit name scopes that FPC will implement. Like the "System.Collection.Generics all three parts will be a symbol so you can't use them in your code". What exactly does that mean? Are there already some documentations, examples, fpc test units?

Mattias

Mattias Gaertner wrote

I meant, can you give me the rules for the dotted unit name scopes that FPC will implement. Like the "System.Collection.Generics all three parts will be a symbol so you can't use them in your code". What exactly does that mean?

That you can't have for example have an identifer "Collection" in the global scope of the interface or implementation section.

Are there already some documentations, examples, fpc test units?

The tests are located in $fpcdir/tests/test and are named tdotunits*.pp. Though I just notice that besides testing for correct compilation the tests never seem to check whether the correct identifier is resolved (e.g. tdotunits2 does never check whether the value is assigned to the correct variable/field). And two of the tests won't be run at all, because they don't start with a "t"... *sigh*

You can also take a look at
http://docwiki.embarcadero.com/RADStudio/XE3/en/Using_Namespaces_with_Delphi but ignore the paragraph about "multi unit namespaces" as this seems to be related to the old Delphi.NET only.

Regards,
Sven

In the unit "System.Collection.Generics" or in the unit using that unit?

Can you fix that?

You can also take a look at http://docwiki.embarcadero.com/RADStudio/XE3/en/Using_Namespaces_with_Delphi but ignore the paragraph about "multi unit namespaces" as this seems to be related to the old Delphi.NET only.

Does that mean FPC will support exactly that or only a subset or will it have some additions?

Mattias

I *think* in both. This feature was implemented by Paul, so your safest bet would be to ask him. :)

Should be possible. I'll add this to my todo list.

I hope Paul implemented all that already when he worked on dotted unit names. :)

Regards,
Sven

If that is true, then I guess it should be easy to implement in the codetools too.

fpdoc is tricky because it has no uses sections.

Mattias

14.04.13, 17:11, Sven Barth ?????:

Indeed. I will improve them.

And two of the tests won't be run at all, because they don't start with a "t"... *sigh*

What do you mean? I made few tests which use units. Units are tested because they are included into uses parts of test files.

Best regards,
Paul Ishenin

14.04.13, 18:08, Mattias Gaertner ?????:

You mean easy implement by me? If so then I don't think it will be easy because codetools code differs from compiler code much :)

If you find any difference with Delphi handling please let me know. During the feature implementation I checked it behavior with Delphi.

As Sven already mentioned FPC will probably start to intensively use dotted unit names for RTL rather soon.

Best regards,
Paul Ishenin

Easy to implement by me. ;)
I thought the unit name spaces are more complicated, but maybe I misunderstood Sven.

Good to know.

Mattias

14.04.13, 18:52, Mattias Gaertner ?????:

I thought the unit name spaces are more complicated, but maybe I misunderstood Sven.

As I remember compiler changes were rather small. You can look at them in trunk r18911 or in paul/namespaces branch.

Best regards,
Paul Ishenin

Thanks.

There are two program files which start with "udots". These won't be compiled during a testsuite run, because only files starting with a "t" are compiled (this is why you can sometimes see units starting with a "t"). So you'd need to rename the program files and the units it uses for testing conflicting namespaces to "t..." and ensure that the renamed units can be compiled themselves as well (so that they won't be counted as failed tests).

Regards,
Sven

+1

The dotted names have been introduced in the .NET experiment, which has been dropped later, but now they have to be for supported for compatibility with newer Delphi versions. But like Delphi provides a number of incompatible versions, FPC IMO should do the same and freeze pre-2000 (D7 compatible), Ansi (D2007?), Unicode (D2009..XE) etc. releases, and should *not* try to merge features from different Delphi versions into only one compiler and RTL.

The same for Lazarus, which also should stop trying to support all Delphi versions in one LCL and IDE. It's obvious that the LCL cannot support Ansi/UTF-8 and Unicode at the same time, this has been discussed already. Also the new XE3 GUI requires a very new component library, in addition to the LCL. Other features, like the dotted unit names, can have an heavy impact on the IDE/code tools (code completion, FPDoc and its editor, Helpfile content...), and also should be supported in different Lazarus versions. The only other solution IMO would require to make many packages polymorphic, so that they can be activated depending on the version of the current project.

Beforementioned program versions must not be absolutely frozen, it may be possible to add some non-breaking support (LazBuild, Generics...) also to older FPC/Lazarus versions, as developer time, bounties etc. permit. Nothing stops FPC/Lazarus versions from being *better* than the compatible Delphi versions :-)

Just my 0.02?
DoDi

Someone recently explained Delphi's namespace usage to me, and gave me a valid example of this.

tiOPF has unit names with the same name, but used by different GUI toolkits. eg: tiMediators.pas is used by VCL, LCL and fpGUI. Each toolkit support has there own tiMediator.pas unit. You need to change unit search paths, so the compiler knows which unit to use.

Anyway, recently somebody added FireMonkey support for the tiOPF mediators (Model-GUI-Mediator design pattern), but found an issue with threading. The tiOPF has a tiThread.pas unit, but FireMonkey's threading works differently.

So instead of littering the tiThread.pas code with IFDEF's, the developor simply duplicated the units (yeah, not too great), but then added the "FMX" namespace to that unit. eg:

tiThread.pas
FMX.tiThread.pas

Now the developer could simply use tiThread in the uses clause of FireMonkey code, because his FireMonkey apps define the FMX namespace, so the compiler and IDE knew which tiThread unit to use. No IFDEF's required!

--------------[ forward ]-----------------

/GUI/FMX/tiMediators.pas
/GUI/FMX/tiListMediators.pas

It involved a bit of mucking around with some of the mediator view classes. eg. TComboBox works differently.

A couple of other units didn't compile, so I duplicated them and added the FMX. namespace?

/Core/FMX.tiThreads.pas
/GUI/FMX.tiGUIConstants.pas

That way we don't need $IFDEFs, just "FMX" in the project unit scope names list. In fact, I don't recall seeing a compiler directive to distinguish FMX and VCL.
Units are often given the prefix. Eg. Vcl.Forms and FMX.Forms.

----------------[ end ]-------------------

PS:
I'm not sure if Free Pascal already supports such namespace / unit scope yet.

Regards,
- Graeme -

How is the namespace passed to the compiler?

PS: I'm not sure if Free Pascal already supports such namespace / unit scope yet.

Mattias

15.04.13, 19:26, Mattias Gaertner ?????:

How is the namespace passed to the compiler?

This is not supported by FPC at the moment but will be implemented before hackaton or on hackaton (probably).

There will be a compiler switch similar to dcc32 -NS switch where you wlil pass namespaces which needs to be checked for short identifiers.

E.g.:

program test;
uses
   SysUtils;
begin
end.

If we compile this with
dcc32 -NSSystem delphi will find System.SysUtils instead of SysUtils. Without this switch recent delphi will give an error because now delphi RTL has no SysUtils unit - it has System.SysUtils.

Best regards,
Paul Ishenin

15.04.13, 19:43, Paul Ishenin ?????:

If we compile this with dcc32 -NSSystem delphi will find System.SysUtils instead of SysUtils. Without this switch recent delphi will give an error because now delphi RTL has no SysUtils unit - it has System.SysUtils.

Just looked at some recent project .dproj file - it stores the next Namespaces (they are set by IDE by default):

<DCC_Namespace>System;Xml;Data;Datasnap;Web;Soap;$(DCC_Namespace)</DCC_Namespace>

Best regards,
Paul Ishenin

Are dotted name spaces allowed too?
For example

-NSXML;my.company

?

Mattias

I would hope so, this is the whole point of namespaces :-)

(sounds better in Dutch where dot=point ;) )

Michael.

15.04.13, 19:53, Michael Van Canneyt ?????:

Yes, you can pas dotted namespaces too.

Best regards,
Paul Ishenin

Trouble is that it has the same problem as the define/ifdef. If you compile in parts and forget to pass the -d (or -NS) to one stage, you get funky errors.

True, one ifdef less in source (since unitname automatically adjusts), but for that it is an very specialized feature, and there probably will be consequences for unit searching also. (similar to the filename case stuff on *nix)

Marco van de Voort wrote

True, one ifdef less in source (since unitname automatically adjusts), but for that it is an very specialized feature, and there probably will be consequences for unit searching also. (similar to the filename case stuff on *nix)

All fair points I guess... I personally don't use namespace named units in any of my projects. I was simply commenting on its functionality - as it was explained to me.

Before, I never knew how it worked in Delphi, and thought it was just an aesthetics thing.

Regards,
- Graeme -

Mattias Gaertner wrote

How is the namespace passed to the compiler?

No idea... but seeing Paul's reply, it seems via the -NS switch, which I gather Delphi IDE does automatically for you, based on project type.

Regards,
- Graeme -

Thank you for correcting the tests. :)

Regards,
Sven

Anthony Walter wrote

Because in theory you should get code insight when you type Identified(dot).

Which theory?

As far as theory goes, I'd say that Code insight usually looks through the scope stack for matches. The scope stack is created by the uses statement, so codeinsight wouldn't work there.

From a style perspective I also tend to avoid underscores in my own identifiers. I reserve underscores for methods you normally shouldn't call (_AddRef), or for imported C code (MAX_PATH, type_).

Maybe.

Also, I am sure you know dotted unit namespaces are an addition to Free Pascal. They are familiar to C#/Java people, and probably look better (style-wise) to them.

I would be very careful with that, since that also raises other expectations the limited dotted concept cannot furfill.

Marco,

Regarding you question about code insight, here are two arbitrary nice features of how code insight can be used with dotted namespaces I captured from Visual Studio (other IDEs and other languages do similar things):

When adding "using" ("uses" in pascal) referecing a unit/assemble/namespace IDEs can show you a list of namespaces to choose from at each dot, and then they filter that list further as you type after the dot:

http://www.codebot.org/fpc/insight_using.gif

This would be analogous to typing "uses SysUtils, MyCompany.Te" and being show a list of namespaces (units in pascal) which were under the domain of "MyCompany" and begin with "Te". The subtle difference between this and using underscores in place of dots is that with each identifier the IDE can validate the prior identifier is a valid name space (and perhaps show you red squiggles), and refresh the list of available items. If you backspace through each dot within the a list you can reopen the insight list show you what can come under each dot. Not that complicated really.

http://www.codebot.org/fpc/insight_type.gif

And the above is useful when either you want to find a type/function/var, but you know it belongs to MyCompany. Much like how you can now say "var X: Classes." and see a list of types in the Classes unit, except using multiple identifier and dot pairs gives better refinement of what to choose from. Consider an example if you were to write a program using components from multiple vendors where the final identifiers might collide. You could use "VendorA.Controls.TDataGrid" or "VendorB.DataWidgets.TDataGrid" to differentiate them, while getting insight into which namespaces each resides (along with what else the vendors provide in their namespaces).

And finally, on the topic raising expectations and attracting more usage... anything which is done, within the spirit of keeping the pascal design clean, which may help and please people is a good thing. I wouldn't be so pessimistic as to say "pascal has gotten worse because its ease of use is attracting a bunch of low skill kiddies" or "we don't want people being attracted to pascal who might complain that it doesn't have feature X, Y, or Z". The more and great variety of people interested in pascal, the better. Period.

Of course the worse thing anyone can do is reply to someones questions with another question "Why would you ever do X when you could do Y instead" , then follow up their somewhat verbose response with brief (lazy) sarcastic attempts to chastise.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20130416/5fb1a683/attachment.html>

True. But the C# namespace concept is totally different from the Pascal one, as I wrote in the previous message.

Pascal would have to make an inventory of all files in the searchpath, not just in a certain (classpath or GAC) location.

IOW, the resemblence of dots in filenames and C#/Java namespaces is only superficial.

There are only 2 differences between what we currently have with dotted unit names acting as namespaces and C# namespaces.

1) You can't have more than one namespace in a file
2) You can't span a namespace across multiple files

Regarding the code insight you asked me about, those two differences aren't relevant to the programmer user experience. You could very well do the same thing in C# (use one namespace per file), and the code insight (just that aspect) user experience in Visual Studio would be the same. That is, you still type "MyCompany." and see a list of sub namespaces or classes or whatever (depending on what precedes "MyCompany.").

No, you don't need a GAC to achieve this. All you need is a list of unit paths, and the IDE can scan those folders for unit names. Something Lazarus already does.

And just to be clear, Visual Studio doesn't use the GAC to search for namespaces,. You have to add a reference to an assembly (somewhat analogous to adding a package requirement in Lazarus). Once a project references an assembly (which can be in another folder, copied to the project bin folder, or it can load the assembly from the GAC), namespaces and types are determined. That is, potential namespaces are determined by your project references (again, analogous to adding a package requirement), and not by scanning the files in the GAC.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20130417/cc3e2320/attachment.html>

Follow up.

I think I found another bug with fpdoc. I believe it parser fails and documentation generation stops if it encounters a generic type declaration like this:

{ THardwareCollection<T> represents a collection of connectable devices such as joysticks }

  THardwareCollection<T> = class(TOwnerCollection<T>)
  public
    constructor Create;
    procedure ScanHardware; virtual;
  end;

Breaks: THardwareCollection"here"<T>
Error: Expected "=" at token "<" in file

What's the best way to search the free pascal mantis bug tracker to see if this issue has already been reported?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20130417/a3dbe3e5/attachment.html>

It has not been reported.

fpdoc currently does not support Delphi style generics. You should use FPC syntax for fpdoc to work.

So you can report this as missing delphi generics syntax.

Michael.

3) it is a special form of namespace that can't contain anything else than units. To contain something else, it must be an unit namespace.

Regarding the code insight you asked me about, those two differences aren't relevant to the programmer user experience

My remark was somewhat compiler specific, but it bleeds through in the IDE too, since in a Lazarus/FPC project, not all used source must be named in the project. Stronger, the project doesn't even exist on a "build" level.

I'm no Lazarus expert, but I assume that bleeds through in the IDE. IOW one can't assume that the project compilation unit list is complete.

No, you don't need a GAC to achieve this. All you need is a list of unit paths, and the IDE can scan those folders for unit names. Something Lazarus already does.

I was wrong however to assume that Lazarus doesn't already constantly monitor filepaths already. I don't know what it does there. I mixed up the compiler and IDE/codetools POV.

Correct.

The IDE and codetools do some more searches than the compiler.

Mattias

In case anyone is interested, I tested the free cmd line tool (doc-o-matic express) for help generation which handles both of these problems (dotted namespaces and delphi style generics). It even has a lot of extra features. Check out the impressive results from a test on one unit:

http://codebot.org/bare/contents.html
http://codebot.org/bare/bare_game_twindowparams.html<http://codebot.org/bare/Bare_Game_TWindowParams.html> -------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20130419/744f857a/attachment.html>