Namespaces in Spring4d code

[EugeneK 22]

Hi

 

Is there any chance that namespaces will be added in Spring4d code? e.g. System.SysUtils instead of SysUtils

[Stefan Glienke 2062]

Why?

[EugeneK 22]

In my projects I don't have anything in 'Unit Scope names' and 'Unit aliases', so it won't compile if I just add it as is. All other 3rdparty libraries that I use have it, so I don't want to add it back.

[Anders Melander 1914]

30 minutes ago, Stefan Glienke said:

Why?

Supposedly compiles faster...?

[Zoran Bonuš 12]

34 minutes ago, Stefan Glienke said:

Why?

I guess to help the compiler a liittle bit,  as explained here:

https://blog.marcocantu.com/blog/2022-december-suggestions-help-delphi-compiler.html

[Stefan Glienke 2062]

The claim that it compiles faster is bogus - prove me wrong. Most compile time from spring4d comes from generics, which I reported years ago.

Also, my suggestion for third-party libraries is to pre-compile them, which removes any dependency on the project options in your project.

 

Currently, Spring4d supports down to XE, and as long as that is the case, I am not putting even more conditionals into the code than there already are.

[EugeneK 22]

37 minutes ago, Anders Melander said:

Supposedly compiles faster...?

Also it forces unified style across all the code and improves readability.

[Anders Melander 1914]

35 minutes ago, EugeneK said:

improves readability

I'm not sure I agree on that.

 

I've just been through a refactoring session where SysUtils was replaced with System.Sysutils which in turn made it necessary to resolve a series of type references as System.Sysutils.PByteArray instead of Sysutils.PByteArray due to a duplicate type declaration. That certainly didn't improve readability.

[Kryvich 166]

Embarcadero can sometimes move system types and functions from one RTL unit to another. Should we care in which specific RTL module a particular system type is declared? The Unit Scope Names setting helps abstract away implementation details.

Edited 7 hours ago by Kryvich

[baoquan.zuo 26]

There is one approach without using many conditional defines:

- Just use fully qualified/scoped unit names in use clauses

- Create a shared .optset to be used by all XE-specific projects

- Use unit aliases to map System.SysUtils to SysUtils, System.Actions to System (Ignore it), etc. in the optset.

 

I did try this way and I am OK with it, but I am not sure what is the limit of the unit aliases/performance boost, an you have to use conditional defines when reference full-qualified type/members of RTL (should be limited).

[Anders Melander 1914]

1 hour ago, Kryvich said:

The Unit Scope Names setting helps abstract away implementation details.

Huh? How do they do that?

Can you give an example?

[Kryvich 166]

1 hour ago, Anders Melander said:

Huh? How do they do that?

Can you give an example?

I mean, you don't have to remember which system unit declares which type. You just write Integer, PByteArray instead of System.Integer, System.Sysutils.PByteArray and that's it!

 

It makes sense to specify a namespace for System/RTL identifiers only in case of ambiguity.

Edited 5 hours ago by Kryvich

[Anders Melander 1914]

2 hours ago, Kryvich said:

I mean, you don't have to remember which system unit declares which type. You just write Integer, PByteArray instead of System.Integer, System.Sysutils.PByteArray and that's it!

You still have to explicitly declare, in the uses clause, where PByteArray comes from - regardless of which form you use.

And in the case of identifier ambiguity there is no difference in how it is resolved, regardless of fully qualified namespace or implicit namespace.

 

So how does that explain your statement:

5 hours ago, Kryvich said:

Embarcadero can sometimes move system types and functions from one RTL unit to another. Should we care in which specific RTL module a particular system type is declared? The Unit Scope Names setting helps abstract away implementation details.

If they move an identifier from one unit to another, you still have to update your uses clause and any explicit namespacing, since Delphi doesn't really have namespaces.  They can hide a move from Foo.SysUtils to Bar.SysUtils but not from System.SysUtils to System.FooUtils.

I guess what you were referring to was a move from SysUtils to System.SysUtils.

Edited 2 hours ago by Anders Melander

[MarkShark 27]

12 hours ago, Stefan Glienke said:

Also, my suggestion for third-party libraries is to pre-compile them, which removes any dependency on the project options in your project.

This is very much a key point in this discussion.   Spring4D includes the very, very nice build.exe tool which quickly and easily builds the library, can run tests, and conveniently adds the appropriate library path, debug path, and browsing paths to the IDE.  I wish all third-party libraries did so!

[Kryvich 166]

@Anders Melander Of course, I wrote about specifying short identifiers like Integer, PByteArray without a namespace inside a code section.

 

Is there anyone here who writes System.Integer, Data.Win.ADODB.TADOQuery etc. in your code? And why?

 

And the second question: if you don't do this for identifiers in your code, then why do it in the uses clause for system unit names?

[Stefan Glienke 2062]

To avoid repeating the unit throughout the source code, you can declare an alias at the top and only explicitly put the unit name there. That, however, only works for non-generic types and consts. I wish it would also work for generics and routines.

[Anders Melander 1914]

38 minutes ago, Kryvich said:

I wrote about specifying short identifiers like Integer, PByteArray without a namespace inside a code section.

Well, you said The Unit Scope Names setting helps abstract away implementation details which was what I have been trying to get an explanation of - but never mind.

 

38 minutes ago, Kryvich said:

Is there anyone here who writes System.Integer, Data.Win.ADODB.TADOQuery etc. in your code? And why?

The example I gave with PByteArray is real; I have a core unit which declares TByteArray (of which PByteArray is a pointer to) as array[0..0] while SysUtils declares it as array[0..32767]. Since these two are ambiguous I have to scope my use of PByteArray when both units are used. No problem, SysUtils.PByteArray(some_pointer) doesn't obfuscate the code much. System.SysUtils.PByteArray(some_pointer) however is bit too verbose for my taste. FWIW, I just resolved it with a local type declaration: type PByteArray = System.SysUtils.PByteArray;

Edited 2 hours ago by Anders Melander