If units are namespaces, why not use them in widgets declarations, automatic, in Lazarus?
When we droped a widget in a Form, ie a TEdit, the declarion would be like this: TForm1 = class(Form)

  Edit1: StdCtrls.TEdit;

end;

Why this? Well, we would not need to use prefixes in the names of our widgets. I could develop a widget called TEdit too, but using my own unit.

All most developers use prefixes in yours classes and functions. Pascal not is C and don't need this. So, why do that?

Marcos Douglas

I just started leveraging this fact in my project. The complaint I bring is that I don't want to use a class object. I want a dedicated NameSpace as a reserved word.

ie.)

NS_APP_FIELDS=class
const
  VALUE1 = 'VAL1';
  VALUE2 = 'Val2';
  VALUE3 = 3;
end;
NS_APP_FIELDS=NameSpace
const
  VALUE1 = 'VAL1';
  VALUE2 = 'Val2';
  VALUE3 = 3;
end;

I recognize it doesn't change much, but it would sure look more industry standardized if this would work. Even If in the interim, NameSpace:=Class ;-) somewhere... But to do it right there should be differences between classes and NameSpaces inside units. Whats even more impressive is the fact that this could be coupled with abstraction

But back on direct topic, I often use unit names to specify which method I want explicitly accessed/used. In my project, sockets, byeArrays mean different things depending on where you are in specific a context. Having the option to clarify where the item is typed was offered way back in Delphi days.

IMO control classes have to be registered, so that a compiled application can work independently from any namespace, unit or directory structure.

That's why the first line above should read
Form1 = class(TForm)
where Form1 is the name of the form object, as stored in the object itself, and TForm is the ClassName in the TForm.ClassType (vulgo VMT).

Why this? Well, we would not need to use prefixes in the names of our widgets. I could develop a widget called TEdit too, but using my own unit.

All existing form objects are stored in Application.CustomForms[], and their controls in Form.Controls. Likewise the class names are usable via RTTI. Adding namespaces (or unit names) would require further table(s), that do not yet exist (except perhaps in debug info).

All most developers use prefixes in yours classes and functions. Pascal not is C and don't need this. So, why do that?

These qualifiers are resolved at compile time, they don't become part of the compiled application.

When in some future time we'll have resources loadable at runtime, the names of the packages (DLL, so) will become important, but only to the resource loader, not to any existing table structure.

DoDi

And what about procedures/functions? This "problem" isn't just about classes...

In C, all the indentifiers would be unique, but not in Pascal. We have units (namespace) so, why use prefixes like TxyzEdit? Why not use, for example, xyz.TEdit ("xyz" would be the company, whatever) in all declarations? Wouldn't more readable? And will have less conflicts with others names of class too. Procedures and Functions, the same: xyz.foo() not xyzFoo() how the most developers like to do.

Marcos Douglas

Maybe the unit names should be shown in the keyword completition list. Then all namespace handling is easier.

g
Michael

We're going to have to get someone to work-around the duplicate identifiers problem too. But as it turns out with my case above, I ran into another problem. Identically named enums types didn't compile b/c they themselves were duplicated. I revised my code to employ nested consts instead of enums, this way I was able to group and simulate enums.

While one can discuss if additional namespace constructs are necessary at all, IMHO if you do, people expect dotted global namespaces, not renaming random identifiers to "namespace"

You are aware that there is a "TObject.UnitName" in 2.4.2 now, which gets the unit name by default from the RTTI? (see
http://wiki.freepascal.org/User_Changes_2.4.2#TObject_class_declaration )

Regards,
Sven

Hi Hans,
I'm not talk about RTTI but style, make code more readable and less duplication of names.

Marcos Douglas

I'm not talk about RTTI but style, make code more readable and less duplication of names.

Working with items of the same name, from different locations (units, namespaces), requires qualifications all over. That waste of characters in source code makes code less readable to me.

DoDi

Waste of characters? Not really. Write xyz.TFoo is not so different of TxyzFoo. There is one char more.
How I will know all prefixes of all libs in the internet? If I choose the prefix "rx", I will have conflicts with RXlib, for example. Graeme chose the same prefix the Lazarus did in some classes: TfpgXXXX ("fpg")

Marcos Douglas

The prefix is not needed. It makes it easier, but is by no means a requirement, as long as you keep the unit names separate.

Compare

Edit1 : myedit.tedit

to

Edit1 : tmyedit

In the second case, you'll cover 99% of all cases.

If by any chance there is an overlap, then the first scenario

edit1 : myedit.tmmyedit

is still an option.

I work 12 years with lots of libraries, and I have exactly once (1 !) encountered a problem with duplicate names; when Delphi introduced strutils, it clashed with rxlib's strutils, which was subsequently renamed to rxstrutils. problem solved.

So namespaces: yes, nice to have.

But do they solve an urgent problem ? I don't think so.

Michael.

Ideas about namespaces have ben collected before.... http://wiki.lazarus.freepascal.org/Namespaces

But in the end, iirc none of them solves the problem. They just move the problem to the next level.

And speaking of namespace, keep in mind, that projects are shared too, if projects refer to namespaces, then those namespace must equal on every single computer.

So if rxlib would take the namespace "rx" (on top of units), and someone else did also take that namespace, then you have the same problem....

Right! But you saw what I written in first mail of this thread? See:
"If units are namespaces, why not use them in widgets declarations, automatic, in Lazarus?
When we droped a widget in a Form, ie a TEdit, the declarion would be like this: TForm1 = class(Form)
Edit1: StdCtrls.TEdit;
end;"

I talked about the Lazarus put the unit name like a prefix in all classes.

Marcos Douglas

I agree. I was using C# for a while and that's when I got used to the idea that I could group consts and methods not associated with objects. I have only one unit that HEAVILY uses namespaces to see what other code might look like. So far I'm pretty impressed with the results.

The problem I'm having that is urgent is that Lazarus won't jump to the methods. I can see that if FPC changes nuances with nested namepsaces someone shouldn't have to play catchup to make changes to codetools. But, these changes have been there for at least a while, and I would like /svn/trunk/ to support them.

The problem namespaces solve for me is to enforce design organization within the group. This unit was selected because it is the foundation unit that facilitates real-time applications and the methods and unit's constants and even data structures' default values when initialized are stored in the ns object.

ns is where I plan to put my "parent" namespace. All other structs/consts/defaults/enums/ etc will be declared there and under children of ns (globals there and children have their own from that point on...). The only way I could reproduce this effort was with separate units. With namespaces - I can organize differing structs even classes within the same unit bypassing the circular reference issue.

IMEO namespaces are something to get EXCITED about. But that's because the project I'm working on in this case is highly complex and requires conscience isolation when mind wrapping... This way I can immediately acquire engineering context and dive-in. Otherwise I have to sift through documentation and code and blah blah blah just to figure out what prior creator was trying to do. Conscience isolation is what makes OOP so valuable to us non-binary life forms ;-) We actually need constructs as building blocks... such as namespaces that help us organize thoughts and methods to perform duties and whatnot.

You right... but, of course at Namespaces will be much longer than "rx"! The "name_of_company" + "name_of_lib" will be a good example.

Marcos Douglas

I know.

But if implemented, I would strongly suggest that this is an option, off by default; I would not want it in my code. I don't see the use of it, but of course each has his way, and if that works better for you, why not...

Michael.

Why would you? If the number of identifier clashes is low, it makes more sense to disambinguate the clashes, and not have to change each and everything on every unitname change.

2011/1/10 Michael Van Canneyt :

Thank you, Michael.

Marcos Douglas

Well, was just an idea, anyway.
I think is more readable use unit.TFoo or unit.FooExec(), for example. So, I do not need to be creating prefixes (even non-existent, perhaps).

Just one more example:
I like the prefix "dx" because make sense with one of the existing projects here in the company, but the DevExpress already uses.

Use prefixes in class names until that is "beautiful"... but I also use it in procedures or functions?
As you guys (who has no problems with identifiers) do?

Marcos Douglas

But it's different from only TFoo, and that's my point.

Duplicate identifiers are used in the same unit in very rare cases only, so that normally a qualification is not you have to use such identifiers, it doesn't matter whether you use unit or namespace names for disambiguation - you always have to qualify.

Otherwise the "uses" clauses make any further qualification optional.

DoDi

ns is where I plan to put my "parent" namespace. All other structs/consts/defaults/enums/ etc will be declared there and under children of ns (globals there and children have their own from that point on...).

You can apply that to your unit names as well.

With namespaces - I can organize differing structs even classes within the same unit bypassing the circular reference issue.

This is not a feature of namespaces, it's a compiler feature. A Pascal (OPL) compiler could allow for circular unit references as well, at the cost of compilation time (eventually multiple passes are required).

IMEO namespaces are something to get EXCITED about.

True, as long as a language has no other means of structuring code. But OPL already has a notion of namespaces, called "units" :-]

Namespaces instead are unrelated to source files, so that a compiler and linker has to know about all source files that contribute to every single namespace. Development systems try their best to hide this consequence, but they are not always successful. In fact .NET needs assembly references in the first place, so that it can know which source modules make up every assembly. Only from that catalogue it's possible to build the namespaces, by extracting the declarations from the assemblies. This additional namespace tree is not required in OPL, where unit names (and packages) already are unique and sufficient for disambiguation.

DoDi

When namespaces correspond to unit names, i.e. disk files, a disambiguation is always possible by adding the parent directory to the unit name. This is not implemented, because there never existed an urgent need for such an extension, but it would always end up in unique references, because file systems disallow for duplicate file names within a folder. Not so for namespaces...

DoDi

That idea has a little problem: In Pascal ABC and abc are the same identifiers while on most Linux filesystems ABC and abc are two different "identifiers". I can even force that situation on Windows with NTFS (yes, NTFS supports case sensitive file names).

Regards,
Sven

Right, this problem had to be handled already. Wirth also made successors of Pascal case-sensitive, but is this something we really want?

DoDi

Hans-Peter Diettrich wrote

Duplicate identifiers are used in the same unit in very rare cases only, so that normally a qualification is not cases because I can't use the identifiers TEdit, TButton, etc.

Then we always will have to invent prefixes for new widgets?

When you have to use such identifiers, it doesn't matter whether you use unit or namespace names for disambiguation - you always have to qualify. Otherwise the "uses" clauses make any further qualification optional.

Yes, in my code... but I'm talk about the engine of Lazarus to write code when we put a widget on the Form.
I proposed write the unit name (default is False, Michael said) to qualifying the classes of widgets.

Marcos Douglas

If you invent a new button, then I guess naming it TButton will be confusing regardless of chosen namespace, since TButton is a well-known name for any Delphi/Lazarus developer.

Yes, but this was just an example.
Another example: A while ago I used the prefix "dx", but then I discovered that DevExpress.com already using this prefix. So, I really would not use TButton or TEdit... but if we want, we could not use?

I think it's harder to have conflicts with the names of units (but they do happen) than with class names.

And if we can "rename", in the code, the names of the units then it would be perfect, IMHO.

Like this:

uses
  CompanyXYZ_StdCtrls as xyzctrls;
var
  b: TButton;
begin
  b := xyzctrls.TButton.Create(Self);
  // some code
end;

We could have big names of units (much less naming conflicts), but with a very lean code.

Just my 2 cents.

Marcos Douglas

... which you can already do. The unit order in the uses clause already determines which identifier is chosen when you do *not* specify a unit explicitly. So just make sure that LCL's TButton is always the default one and you can still use your own TButton by prefixing it with your own unitname. All you want is already there and seems to cover 99% of the usecases.

That looks a bit like Modula to me.

But I can register a component called TButton?
Because that I proposed the Lazarus put the unit name in the code, automatic...

Marcos Douglas

I do not know Modula. This is good, in Modula?!

Marcos Douglas

http://en.wikipedia.org/wiki/Modula-2

?
?

Marcos Douglas hat am 12. Januar 2011 um 18:05 geschrieben:

No, that would conflict with the LCL TButton. See the FCL function FindClass. ?

Because that I proposed the Lazarus put the unit name in the code, automatic...

Just use the right unit order.

Mattias
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20110112/f3c99ffc/attachment.html>

2011/1/12 Mattias Gaertner :

> But I can register a component called TButton? No, that would conflict with the LCL TButton. See the FCL function FindClass.

I know.

> Because that I proposed the Lazarus put the unit name in the code, > automatic... Just use the right unit order.

What is that mean?

Marcos Douglas

It means, that instead of

use StdCtrls, MyEdit;
TForm1 = class(TForm)
  e1: StdCtrls.TEdit;
  e2: StdCtrls.TEdit;
  e3: StdCtrls.TEdit;
  e4: StdCtrls.TEdit;
end;

.. you can simply use:

use MyEdit, StdCtrls;
TForm1 = class(TForm)
  e1: TEdit;
  e2: TEdit;
  e3: TEdit;
  e4: TEdit;
end;

Mattias

Ah, okay, I remembered this... but in Delphi I used <StdCtrls, MyEdit> instead of <MyEdit, StdCtrls>. Right to Left, no? Anyway... this is a "hack" not a "pure" implementation. You use the design time of TButton (LCL) but in runtime the button will behave differently. I think this is not a good idea (I used this hack to extend the default components in Delphi, e.g., coloring the all TDBGrid's lines in a project).

Marcos Douglas

If I see that right, then even if Lazarus would implement this it would need a new FPC release with an extended FindClass to enable this. As the current release is just two months old this might not happen in just some weeks.

Regards,
Sven

Sounds good for me.
"Before later instead of never" ;-)

Marcos Douglas

Hi Sven.
Do you have any news about it?

Best regards,
Marcos Douglas

Am 20.08.2017 18:55 schrieb "Marcos Douglas B. Santos via Lazarus" <

: On Wed, Jan 12, 2011 at 3:53 PM, Sven Barth

need

> a new FPC release with an extended FindClass to enable this. As the

current

> release is just two months old this might not happen in just some weeks. Hi Sven. Do you have any news about it?

Why should I have any news? I merely stated what would need to happen if this is to be changed.

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

It was just a question... never mind. Thanks.

Best regards,
Marcos Douglas