Hi all,

what FPC version support dotted unit name?

From the wiki: http://wiki.lazarus.freepascal.org/FPC_New_Features_Trunk

"Delphi-like namespaces units
Overview: Support has been added for unit names with dots."

So, I believe that if it refers to trunk, it should be about 2.7.1 I don't understand if it is already implemented or if it will be a future feature.

Thank you!
Kjow

PS when this feature will be in stable trunk? (approximately)

New_Features_Trunk contains new feature of the trunk compiler. If the feature is present in the released compiler - it should be removed from there. If the feature is not yet ready - it should not be there.

PS when this feature will be in stable trunk? (approximately)

Depends on what you understand by "stable trunk".

This feature is already in trunk. You can use units with dots in 2.7.1 and even Lazarus supports them (well, maybe not everywhere).

Best regards,
Paul Ishenin.

2011/11/3 Paul Ishenin :

Thank you very much :)

Best Regards,
Kjow

Sorry about my low knowlegde, maybe i am the most slow-learning mailer of this list but i don't understand the advantage of using dots on unit name. Could someon explain it to me?

2011/11/3, Kjow :

William Oliveira Ferreira wrote

Sorry about my low knowlegde, maybe i am the most slow-learning mailer of this list but i don't understand the advantage of using dots on unit name. Could someon explain it to me?

Say you use a bunch of units where XXX is defined multiple times, once in each unit.

If you refer to XXX alone the actual XXX being referred to is determined by the search logic of the compiler which is governed by the scope rules within your unit and by the order of the uses clause. So arbitrary changes in the unit ordering can change the semantics of your code.

But if you really want to be sure that UnitX.XXX is the XXX being referenced you need to refer to XXX with the unit name prefix to ensure that.

This happens to me when I declare a method of a class as Inc to increment some field value in the class. Within the Inc method I need to call System.Inc to actually do the incrementing. Without the System prefix I would get recursion since the Inc method would call itself.

Rich S.

Thanks, becames more clear to me!

2011/11/3, Rich Saunders :

This is the explanation for using unitname.identifier, which worked since many years.

Dotted unit name means dots in the unit name itself. For example an.example.pas. I don't know a good example.

Mattias

Mattias Gaertner wrote

This is the explanation for using unitname.identifier, which worked since many years.

I was just about to say the same thing.

Dotted unit name means dots in the unit name itself. For example an.example.pas. I don't know a good example.

I don't see any use for it either. It seems to be one of those things Borland introduced with or after Delphi 8 (aka Delphi for .NET). Basically trying to copy features from .NET for no good reason. And we all know how great an idea that was.

Weep, then, because as of Delphi XE2, they started using it a lot.

Michael.

And, I believe, it will be usefull for JVM port.

Regards,
?ilvinas

Sorry about my low knowlegde, maybe i am the most slow-learning mailer of this list but i don't understand the advantage of using dots on unit name. Could someon explain it to me?

It's not an advantage, only a relict from the (never finished) .NET experiment. It's kind of emulation of the .NET namespaces or assemblies, where e.g. System.System could denote the Delphi System unit in the .NET namespace (or assembly) System.

As others already pointed out, dotted unit names can cause problems with Delphi qualified names. Without dotted unit names "a.b.c" (unit.object.method) is somewhat easy to parse, since only "a" has to be searched in the used units list. But with dotted names the search also must try to match "a.b" (or more) with a unit name. You may get wrong results, when unit "a" contains a record or object variable "b" with field "c", and a variable "a" in some other unit refers to an record (or object) with fields "b.c".

There exist more relicts from .NET, like Unicode names for identifiers. Since Delphi identifiers are case insensitive, the lookup of an identifier then can be quite time consuming. While with ASCII names only the "capital" bit must be cleared for all characters, in order to make an identifier name unique (all uppercase), no such simple mapping exists for non-ASCII characters. In C or C# all identifiers are case-sensitive, so that no ToUpper or ToLower are required before the lookup of an identifier, and consequently it doesn't matter whether an identifier contains strange characters. IMO it were better to make Delphi identifier names case sensitive at the same time, at least when they contain non-ASCII characters.

DoDi

<michael.vancanneyt at .....> wrote

Weep, then, because as of Delphi XE2, they started using it a lot. From the CodeRage 6 videos all I could see is that they now

differentiate between VCL (eg: vcl.forms.pas) and FireMonkey (eg: fm.forms.pas) units. I don't have a copy of XE2, but other than to try and prevent confusion in the support forums by now referring to a specific framework's "forms.pas" unit by pre-pending it with the framework name.... In what other way are they using it where it is really useful? [this is a honest question]

Wait, now i?ve better understand. FPC Team already added this feature to compiler, ok, but, add it just to be delphi XE2 compatible? ________________________________
William de Oliveira Ferreira
Bacharel em Sistemas de Informa??o

2011/11/4 Graeme Geldenhuys

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20111104/4af4ef90/attachment.html>

William Oliveira Ferreira wrote

Wait, now i?ve better understand. FPC Team already added this feature to compiler, ok, but, add it just to be delphi XE2 compatible?

Dotted unit names were already introduced by at least Delphi 2005 (some sources even report Delphi 7) - Note: I don't count Delphi 8 as this was a .NET only release.

Regards,
Sven

I don't think that Embarcadero considers dotted unit names as a relict as they've improved the concept with a "default namespace" in XE2 (I don't know whether I personally consider that as a improvement though ^^) and also introduced dotted names for all RTL, VCL and FireMonkey units.

Regards,
Sven

Mattias Gaertner wrote

Dotted unit name means dots in the unit name itself. For example an.example.pas. I don't know a good example.

Well, if unit names are tied to file names and embedded dots are becoming more common in file names, then I can understand the "pressure" to relax the unit naming rules to also allow for embedded dots.

But, no, I do not foresee the need in my work.

Hello,

For me, this makes perfect sense, because of many reasons. Here are a couple.

I work on several open source projects, which have in common that all these projects are marked with the abbreviation before the actual unit name. For example with Graphics32 it is 'GR32_'. Replacing the underscore with a '.' would make it appear more logical from a pascal point of view (underscores shall be avoided in favor of CamelCase) and the handling of units look more like records then.

In my second project I have another example where it makes sense from a hierarchical point of view. There I have implemented dozens of filters, with lots of optimizations resulting in a vast amount of code. When I wanted to split this code into several units I thought, that it should have the name Filters first. But, to give an example, this would result in 'FiltersButterworth', 'FiltersChebyshev' and 'FiltersBasic'. It just seems to be odd in the english language, where it would rather be 'ButterworthFilters', 'ChebyshevFilters' and so on.

Separating the names by something like a '.' would make much sense in my opinion.

I have never used .NET, nor am I a Delphi fan-boy, but I think this scoping is useful and I hope it will be supported by FPC. It is discussable, whether it shall be used in Lazarus, but it should be supported.

Christian

I don't think that Embarcadero considers dotted unit names as a relict as they've improved the concept with a "default namespace" in XE2 (I don't know whether I personally consider that as a improvement though ^^) and also introduced dotted names for all RTL, VCL and FireMonkey units.

Well, so what's the role of "Delphi" at all? What remains is an IDE and a compiler, with various GUI extensions. Will Lazarus follow this route
- should it ever???

We have enough problems in implementing a VCL compatible LCL, with attempts to make it compatible with various widgetsets, and with new Delphi versions. All this could be trashed in an attempt to add FireMonkey compatibility. It would be better to start a very new project for that purpose, whose IDE could be based on the LCL, like the Delphi IDE is based on .NET since D20xx.

DoDi

Hans-Peter Diettrich wrote

There exist more relicts from .NET, like Unicode names for identifiers.

Unlike dots in unit names, this feature is useful for people in a general way, not just for .Net / Java compatibility. Pretty much every programmer which isnt fluent in english would benefit from it.

Since Delphi identifiers are case insensitive, the lookup of an identifier then can be quite time consuming.

have you ever run lazarus/test/lazutils/testunicode.lpi ? Or done any performance tests on the subject?

6 million lower case operations on strings of aprox. 25 utf-8 chars long take aprox. 1 second.

So I really doubt that any project build process could be slowed significantly by the cost of doing Unicode lowercase or Uppercase.

The version from iconv is 2,5x slower then the one in LazUtils, but then it's a choice people can make, use slower iconv or faster Pascal =)

Christian-W. Budde wrote

I have never used .NET, nor am I a Delphi fan-boy, but I think this scoping is useful and I hope it will be supported by FPC. It is discussable, whether it shall be used in Lazarus, but it should be supported.

In 2.7.1 this is already supported, so you can play around with it already (2.6 won't contain it though).

Regards,
Sven

Well, Lazarus IS basically an IDE with various GUI extensions. The dotted name space feature is provided by the compiler which is in our case FPC (or did I miss something that we now call the compiler Lazarus as well :P )

In the end we might not need to add FireMonkey compatibilty completely by ourselves, as FireMonkey is already FPC compatible (Embarcadero uses FPC for iOS!). Also one Embarcadero employee stated that they want to keep it compatible so that they can provide it somewhen in the feature officially for FPC as well. And the original version of FireMonkey, KsDev was developed for Lazarus as well until Embarcadero hired the developer and bought the rights for KsDev.

Regards,
Sven

Hans-Peter Diettrich wrote

Well, so what's the role of "Delphi" at all? What remains is an IDE and a compiler, with various GUI extensions.

Lazarus is already usable with 3rd party libraries, like KOL-CE works. It also has non-GUI extensions, like fcl-web. That does not change the fact that the LCL is a core part of Lazarus.

About FireMonkey, I think that people that want to use it with Lazarus should ask Embaracadero. Maybe they would add that if there are customers.

?

"Christian-W. Budde" hat am 4. November 2011 um
13:04 geschrieben:

If I understand you correct: it looks nicer.
?
Dotted unit names gives no technical advantage. It does not even allow to write much shorter code like the recent enumerators.?
?
About "more pascal":
The dotted unit names break the pascal rule that the last scope wins. For example "uses unita.unitb, unita;" makes no sense, because the namespace unita hides the unit unita, even though the unit comes after the namespace. I doubt that this namespace concept makes Delphi/ObjectPascal easier to learn/use. At the moment I guess the opposite is true. Has someone experience with namespaces and newbies??
?
?

It is supported by FPC and I implemented a few things in the IDE. "Find declaration" does not yet support it.?
?
Mattias
?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20111104/5b783c40/attachment.html>

Lazarus only supports one GUI: LCL. Adding fpGui shows part of the problems, which will occur with a very different GUI API, like FireMonkey.

The dotted name space feature is provided by the compiler which is in our case FPC (or did I miss something that we now call the compiler Lazarus as well :P )

The new strings also are an FPC issue, which may require a different LCL. IMO it's not a good idea to mix new Delphi features with attempts to provide a single development environment.

Embarcadero could not provide designers for FireMonkey right now, and Lazarus will run into the same problem - as can be seen with the fpGui widgetset (which is more LCL compatible than FireMonkey or KsDev). Embarcadero failed with a VCL.NET, now they even don't try to provide a VCL.FireMonkey. Lazarus is even more problematic, since it cannot load a different component library dynamically, instead it must be rebuilt for a different FMCL.

DoDi

Hans-Peter Diettrich wrote

Lazarus only supports one GUI: LCL.

False, KOL-CE works in Lazarus too.

The new strings also are an FPC issue, which may require a different LCL.

Based on what you say that? I fixed trunk usage with FPC 2.7 today with trivial changes, so the new strings are not problematic.

Now your comments are getting even wierder.

Did you actually ever use LCL-fpgui?

It looks like you are not aware that since ever Lazarus supports designing for any widgetset regardless of the widgetset of the IDE.

I can even give you a screenshot:
http://www.vhpd.de/wp-content/gallery/lazarus-tutorial-win-ce/vhpd_lazarus_wince_s4.jpg

aham, so how do you explain that?

I cannot confirm that, seeing no such option in the IDE.

> The new strings also are an FPC issue, which may require a different LCL. Based on what you say that? I fixed trunk usage with FPC 2.7 today with trivial changes, so the new strings are not problematic.

I also don't know about the outcome of the discussion and consequential implementation. Where can I look to learn more?

No, see above. The last state was "partially implemented" AFAIK.

It looks like you are not aware that since ever Lazarus supports designing for any widgetset regardless of the widgetset of the IDE.

I know what problems result from controls with incompatible properties, not expected by the designer or OI :-(

I can even give you a screenshot: http://www.vhpd.de/wp-content/gallery/lazarus-tutorial-win-ce/vhpd_lazarus_wince_s4.jpg

Sorry, I don't understand what you want to demonstrate?

DoDi

I cannot confirm that, seeing no such option in the IDE.

Well, do you have it installed? Or at least have you read http://wiki.lazarus.freepascal.org/KOL-CE this ?

From the CodeRage 6 videos all I could see is that they now

differentiate between VCL (eg: vcl.forms.pas) and FireMonkey (eg: fm.forms.pas) units.

Too bad... now they will face problems when refactoring the framework, possibly causing users to create ifdefs in uses clause. I don't really know the compatibility between VCL and FireMonkey, but if many widgets have the same properties and methods, include file hack (as used in FPC for using include files from different directories depending on target platform) should be used instead.

> I cannot confirm that, seeing no such option in the IDE. Well, do you have it installed? Or at least have you read http://wiki.lazarus.freepascal.org/KOL-CE this ?

My point was: *when* a widgetset can be added to the LCL, then no problem.

The Delphi fm.forms.pas vs. vcl.forms.pas names suggest to me, that FireMonkey could not be integrated into the VCL, so that LCL integration is questionable.

DoDi

Hans-Peter Diettrich wrote

I know what problems result from controls with incompatible properties, not expected by the designer or OI :-(

Using a different LCL Widgetset then the one that the IDE uses cannot generate problems with the designer. This is impossible, because the interface seen by the designer is the LCL, not the LCL Widgetset. And the LCL does not change even a bit across widgetsets.

Problems can come across different LCL versions, but this is unrelated to the topic.

> http://www.vhpd.de/wp-content/gallery/lazarus-tutorial-win-ce/vhpd_lazarus_wince_s4.jpg Sorry, I don't understand what you want to demonstrate?

You wrote:

<quote>Lazarus is even more problematic, since it cannot load a different component library dynamically, instead it must be rebuilt for a different FMCL.</quote>

So I show a screenshot proving that you don't need to use the IDE in Windows CE to write Windows CE applications. 1 IDE built for whatever widgetset can write software for any target.

Or did I missunderstand what you were trying to say?

Why do you care about this now? Do you have many Firemonkey applications you need to support in Lazarus?

We are not planing to add another framework to lazarus (firemonkey like or another) or support firemoney development in Lazarus.

And if needed Lazarus designer can be used for non LCL controls today and we will extend it if there will be demand.

Best regards,
Paul Ishenin.

VCL and FireMonkey aren't that compatible. They simply decided that they want to use simple unit names for FireMonkey as they did for the VCL originally.

Regards,
Sven

Hans-Peter Diettrich wrote

The Delphi fm.forms.pas vs. vcl.forms.pas names suggest to me, that FireMonkey could not be integrated into the VCL, so that LCL integration is questionable.

Did you ever come to the conclusion that Embarcadero didn't WANT FireMonkey to be integrated into the VCL? Perhaps because they realized that their VCL is to Windows-centric (unlike Lazarus' LCL).

Regards,
Sven

You are aware that Delphi XE2 contains a FireMonkey designer that is integrated into the IDE?
And Lazarus can also be used to design applications based on non-LCL interfaces like fpGUI if designers for that are written which use the non-LCL-designer interface provided by the IDE.

Regards,
Sven

Hello,

I'm wondering if for the sake of backward compatibility people will start to ask (Embarcadero) to map dotted names to a single name (i.e. Rtl.SysUtils -> sysutils).

thanks,
Dmitry

Paul Ishenin wrote

We are not planing to add another framework to lazarus (firemonkey like or another) or support firemoney development in Lazarus.

+1 FireMonkey integration in the LCL is both a fiction (as in I never heard anyone say he would work on it) and useless.

We are not like Mono which blindly follows their master. Real work is advancing the LCL, not introducing support to unrelated frameworks.

05.11.11 21:34, dmitry boyarintsev ?????:

It is available today if you use "unit scope names" option in IDE or using a compiler switch. Moreover this options is set by default to "Winapi;System.Win;Data.Win;Datasnap.Win;Web.Win;Soap.Win;Xml.Win;Bde;System;Xml;Data;Datasnap;Web;Soap;Vcl;Vcl.Imaging;Vcl.Touch;Vcl.Samples;Vcl.Shell"
- so old uses strings will work.

Best regards,
Paul Ishenin.

This is what I wanted clarified :-)

DoDi

Right :-)

The LCL also had been easier to implement, when it had followed the (more) platform-independent CLX.

DoDi

As already mentioned: *when* a widgetset has an LCL interface (API), it's just another widgetset - no problem.

But when a widgetset like FireMonkey comes with its own API, defined by Delphi and *incompatible* with VCL/LCL, any number of problems can occur. Different components can have the same class names, LCL components will not fit as clients into forms or controls of FireMonkey etc. :-(

DoDi

Felipe Monteiro de Carvalho wrote

We are not like Mono which blindly follows their master.

Sometimes I would have to disagree with you on that statement. :)

This is both a problem for the Lazarus project and the FPC project. I even remember somebody saying "if Embarcadero jumps off the cliff, so would we". Please don't flame me for this reply. You posted such statement - which is just not true.

The only difference between Lazarus and Delphi now, is that Lazarus (and FPC) is starting to lag behind - now that Embarcadero is finally progressing the Delphi language and IDE (after Borland and CodeGear failed).

and as will be revealed in a few weeks, their (RemObjects' actually) jvm compiler aka Oxygene will benefit from the language construct. then again, both that jvm and .net targets are compilers of RemObjects with SOME differences to language constructs and syntax.

why in win32/win64/macOSX this should be a requirement other than maybe package-namespace-denotion is beyond me. In a java (packages) or .net (assemblies) environment they are only that: namespaces. (well, maybe in java the public class has to be atomic in a single file too :-))

kind regards,
Dimitri Smits