Hi!

we need to decide what to do with Generics.Collections implementation.

Lazarus team suggest to add this package as one of sparta packages (for example components/sparta/generics) but in some of my experimental branches it is used deeper than in sparta packages only (LCL, main IDE files or even in other basic libraries unrelated to Lazarus). I'd like to see it as part of RTL.

Any feedback or suggestion?

current version: https://github.com/dathox/generics.collections

The Generics.Collections should be added to RTL or as a FPC package.

Is there some problem in your implementation that Laz team decided to add it as Lazarus package? If so, is it fixable? :-/

current version: https://github.com/dathox/generics.collections

2016-01-26 22:43 GMT+01:00 silvioprog :

Yes. The biggest problem is that the Generics.Collections is not already in RTL. ;) I need this for all my "Sparta packages".

I guess this is good time to ask, how would the community feel about setting a new standard for Free Pascal units going forward? I am thinking that since FPC 3.0 is now official we don't really have a good excuse to start using many of the great new language features it brings, such as dotted name spaces, type helpers on intrinsic types, and of course the now good working generics.

I would propose we start migrating new units to this type of standard:

unit Core.Text;

New string related routines go here, including type helper extensions to the string type. It may incorporate my fast unicode string search and splitting engine along with the type helper StringHelper with methods such as Split, Join, BeginsWith, EndsWith, and so on.

unit Core.Collections;

New generic container types go here including Array<T>, ArrayList<T>, and possibly my multicast delegate TDelegate<T> (see this page http://www.codebot.org/delphi/?doc=9568).

unit Core.Network;

New basic socket class with other socket or network types such as TAddressName (record type with implicit conversion from string and Resolve method). Also the unit would includes an interface type for asynchronous network requests.

The "Core" part of the namespace indicates that these units are officially maintained by the Lazarus and Free Pascal committee members (those with svn commit rights) and are included with every distribution of Free Pascal. I think we could create several of these "Core" units to better organize a Pascal library which incorporates many of the newer and useful language features added since FPC 2.6.4.

What do you think about this idea of adopting this new Free Pascal library standard which I believe would result in a cleaner organization of files and perhaps better discovery of functionality for users?

I'd also like to add that there might be more names under a namespace than just two (e.g "Core.Text"). For example:

unit Core.Collections;
unit Core.Collections.Specialized;
unit Core.Text;
unit Core.Text.Xml;
unit Core.Text.Regex;
unit Core.Network;
unit Core.Network.Http;
unit Core.Network.Ftp;
unit Core.Network.Storage;
unit Core.Encryption;

And so on.

[...]

I already use dotted namespaces for my units, and IMHO it is a nice Delphi/FPC feature. :-)

I agree with all your ideas, but I don't know how FPC/Laz team would accept and adopt this new standard.

Anyway, is there any place where I can find the code that you proposed? It sounds a very nice feature.

Wow, it would be awesome. *-*

The reason your collection was not added as a package to FPC was that there were some compiler bugs at the time. If these bugs are fixed, I see no reason why the package should not be added to FPC.

Can you remind me the bug ID ? then I will .

what is the point of that ?

what does it mean?

We don't need to make the language c-sharpish for the sake of it...

Michael.

add

in

> RTL. ;) I need this for all my "Sparta packages". The reason your collection was not added as a package to FPC was that

there

were some compiler bugs at the time. If these bugs are fixed, I see no reason why the package should not be added to FPC. Can you remind me the bug ID ? then I will main reason is Collections.Defaults. I'm definitely not a fan of the

manual interface building it does, because I don't want to have to maintain that, just in case we change some implementation detail in FPC that this unit happens to rely on, maybe even only in a subtle way. No performance gain is worth this potential maintenance nightmare. And until I had the time to thoroughly check the implications that this unit has I won't add the code to the RTL (just in case: rtl-objpas or rtl-extra, not the bootstrapping RTL).

Regards,
Sven

While I am not opposed to this, some issues:
- Delphi compatibility?
- The compiler does not have a namespace directive, making this purely a more typing operation. What is the added value in that ?
- Who will document all this ?
- Core as the base word is probably a very poor choice, since everyone is going to pick that as the start of his collection.

That said, my own idea was to recreate the Delphi namespaces combined with string = unicodestring. just to say I do not oppose such a shift.

Michael.

Yes, I had a nagging feeling there was something else still...

And please, not in rtl-objpas. New package rtl-generics or fcl-generics.

Michael.

"Sven Barth" wrote

The main reason is Collections.Defaults.

I meant Generics.Defaults of course ^^

Regards,
Sven

Michael,

I see the many benefits of dotted namespace units.

1) Authorship.

Instead of using cryptic prefixes (Rx, Syn, Id, and so on) if we promoted the use of namespaces we might someday the full names denoting ownership more clearly. That and there would be less me creating unit names conflicts (My StrTools vs your StrTools).

2) Discovery

If you have groups of related functionality from a vendor it's easier to discover with code insight tools using dots. For example Indy (dot) <browse list and pick> Log (dot) <browse logging routines and pick> Debug (Out of Indy.Log.Files, Indy.Log.Stream, Indy.Log.Event)

3) Organization

I have a set of string manipulation routines. The LCL has a set of string manipulation related routines in a few units. Other people have string manipulation routines in their units. Wouldn't it be nice if I could find all string related routines under a one category like "Text", rather than trying to find the string functions I need either from SysUtils, or StrUtils, or LCLProc, LazUTF8, or Regex, or MyOwnStrUtils. When Core.Text ought to cover all the basics of Text, Core.Regex would cover regular expression, and maybe we could add a Core.Text.Encoding if needed.

4) Maintenance

I don't know about you, but when working with the LCL I often have trouble deciding where some new or extra functionality should go. There was a recent issue with this and the IsIdentifier function in mantis. Did it go into LCLProc, or StrUtils, or where? With buckets like Core.Text, it would sure make it easier to decide.

4) Grouping

Wouldn't it be nice if controls came under their own group first rather than at the end? Currently people names units things like ShellCtrls, GridCtrls, or DbCtrls. Wouldn't it be nice if you could find all possible control units in source code by simple typing "Lazarus.Forms.Controls (dot)" and seeing things like "Grids, Shell, and Database" in the list of available units? Or maybe if you were dealing with web rendering toolkit it might be "Lazarus.Web.Controls".

Perhaps you think this is too much typing, but code tools allows you to pick a value after a few keystrokes. Also consider the typing saved in not having to type TWebEdit or TWebGrid or TWebCheckBox or whatever you're calling your web engine visuals. You can simply call it TEdit and TGrid and TCheckbox. Think about all that typing saved (you only need to add a uses clauses once in a unit, but how many times do you need TEdit? Sometimes it's quite a lot.).

If you want some examples, look at my Bare library structure:

http://www.baregame.org/#bare_game
http://www.baregame.org/#bare_geometry
http://www.baregame.org/#bare_text
http://www.baregame.org/#bare_text_xml

already

maintain

As long as it's not in the bootstrapping RTL I don't really care where we put it ;)

Regards,
Sven

2016-01-27 8:06 GMT+01:00 Sven Barth :

But what is your point? I don't have any problem with maintenance that and I can adjust this in the future if needed :P. Interfaces are stable part of language. If something will be changed in that matter then all existing codebase will be broken, not only for Generics.Defaults.

Did you plan to implement better way than "manual interfaces" for _LookupVtableInfo, _LookupVtableInfoEx in Generics.Defaults? I won't rewrite well tested parts of library.

Just let me know what is your plan. If you wan't it in FPC RTL then it will became part of sparta packages in Lazarus. The current stalemate is blocking my job. Any predictable timeline? If it will take you another year ot two, then better solution is putting it in components/sparta.

It is very basic and key library for whole Delphi (and for many OS libraries) ecosystem, in that case: rtl-generics sounds good for me.

Anthony Walter wrote

Michael, I see the many benefits of dotted namespace units.

Yes, they are the same ones everyone cites.

None are very convincing. The only one - and minor at that - is the discovery.

Take for example your "TEdit" versus "TWebedit" argument:

I WANT to see TWebEdit, so I am reminded that I am programming in web, not in LCL. I use prefixes in my class names exactly to KNOW which class I am using, without having to look at the uses clause and possibly figure out the order in which units appear.

As I said, I am not opposing this, but I do not think that dotted names are the fetish that most programmers seem to take it for. It's a matter of preference.

Michael.

Micahel,

Do you care to address the issues I raised with the inconsistency of string related functions I raised? Specifically the part about string functions in SysUtils, StrUtils, LCLProcs, LazUTF8, among other units where string related routines are scattered. Also strings aren't the only types where we have these scattered around problems.

On Wed, January 27, 2016 08:57, Anthony Walter wrote:

Hello,

Alright. So what is the authorship of the default units and how does it fit to Delphi compatibility?

Nobody prevents vendors to use their namespace now, right?

The reason of current distribution is primarily due to multiple sources. See http://wiki.freepascal.org/Unit_categorization (now certainly incomplete, but still showing the point). Certain functionality gets to the FPC codebase due to compatibility with Delphi, etc., other stuff is added by us due to missing functionality (which may get added under a different name and to a different unit in Delphi later), etc. Lazarus decides on what to add where independently based on their needs. And so on. How could namespaces solve that?

Not really - it would be easier only until the point when someone else than the original inventor of the naming system comes with something not fitting either of the categories perfectly (guaranteed to happen sooner or later). You may be perfectly clear where it belongs, while somebody else may have a different view / expectation. There is no golden rule, as simple as that. The only way to keep one consistent system is having the system managed centrally, but that doesn't work if there are at least three independent sources (FPC, Delphi and Lazarus).

.
.

I'm not in the position to comment proposals for Lazarus unit names, so I'll skip this one.

Just my 2 cents...

Tomas

On Wed, January 27, 2016 09:46, Anthony Walter wrote:

Anthony,

I believe that I covered this one in my response at least partly - the scattering is due to creation of routines by different people from different teams. It is related to history and compatibility. I dont' see how namespaces might solve this.

Tomas

I definitely care to address this, but they are IMHO not an argument for namespaces. (I am assuming you want to make a case still, if not you can ignore the rest of the mail :-) )

These issues can perfectly be solved without namespaces: put everything in StrUtils (in the case of strings).

The LazUTF8 routines exist for 2 reasons:
- The decision of Lazarus to use UTF8 as a base string at a time when FPC didn't support it properly.
- The much slower release cycle of FPC compared to Lazarus.

These reasons are historical and at least the first one can be solved easily today. The second cannot be solved.
Neither are a compelling reason to start namespaces IMHO.

I don't think namespaces are the holy grail.

Assume we introduce namespaces, do things 'Properly' and introduce Core.FileUtils
Core.StringUtils
(the names are just examples, to make a point)

Now let's take example existing routines such as
ExtractFilePath
ExtractFileName
Where do we put them ?

Both units are a candidate. The former because it is about filenames. The latter because they are purely string operations. Your namespace doesn't solve this problem.

If I am a newbie, and I am looking for something like ExtractFilePath, where do I start looking ? Namespaces do not help me in the slightest.

In short, I program since 30 years without namespaces. I have never ever come accross a problem where I thought that namespaces would be an added value.

Once more, the above is purely theoretical discussion; I am not opposing anything, just pointing out that the use of namespaces is and remains a matter of preference (or even fashion/hype).

As for the actual problem of scattered functionality: Please do make proposals, I am all for more logically organized units (or even less units).

Michael.

It seems we are of the same mind here :-)

Michael.

Maciej Izak wrote

Just let me know what is your plan. If you wan't it in FPC RTL then it will became part of sparta packages in Lazarus.

It has tu be duplicated in Lazarus anyway if you plan to use it in Sparta code. The same was with AdvancedIPC unit.

The problem is that it first comes to FPC trunk and then it takes some time until it appears in FPC stable. Lazarus should support 2 latest FPC stable releases. (Although external packages don't really have to.)

And then there is the problem with duplicate unit names. The Lazarus version of your units could e.g. use an extra namespace.

Ondrej

2016-01-27 10:51 GMT+01:00 Ondrej Pokorny :

Maybe is good idea to follow Delphi standards and add System.* namespace for FPC RTL modules. Delphi allows following additional compiler switches to handle System namespace:

Unit scope names (-NS):
-NSSystem.Win;Data.Win;Datasnap.Win;Web.Win;Soap.Win;Xml.Win;Bde;System;Xml;Data;Datasnap;Web;Soap;Winapi;Vcl;Vcl.Imaging

Unit aliases (-A):
-AGenerics.Collections=System.Generics.Collections;Generics.Defaults=System.Generics.Defaults;WinTypes=Windows;WinProcs=Windows;DbiTypes=BDE

For Lazarus could be added "Lazarus.*" namespace.

version of your units could e.g. use an extra namespace.

> Maybe is good idea to follow Delphi standards and add System.* namespace

for FPC RTL modules. Delphi allows following additional compiler switches to handle System namespace:

Support for the unit scope parameter is planned. We won't support unit aliases however.

Also there won't be any quick decisions regarding this, especially considering the core RTL units as we're still supporting 8.3 systems.

Regards,
Sven

"Maciej Izak" wrote

2016-01-27 8:06 GMT+01:00 Sven Barth : > > I'm definitely not a fan of the manual interface building it does,

because I don't want to have to maintain that, just in case we change some implementation detail in FPC that this unit happens to rely on, maybe even only in a subtle way. No performance gain is worth this potential maintenance nightmare.

But what is your point? I don't have any problem with maintenance that

and I can adjust this in the future if needed :P. Interfaces are stable part of language. If something will be changed in that matter then all existing codebase will be broken, not only for Generics.Defaults.

That is not true. Your code relies on implementation details. All other code that uses interfaces as they are supposed to be used will continue to work correctly after a recompile.

Did you plan to implement better way than "manual interfaces" for

_LookupVtableInfo, _LookupVtableInfoEx in Generics.Defaults? I won't rewrite well tested parts of library.

And I don't want to add code that relies on implementation details like that! At least not without thinking through the implications of that code.

Just let me know what is your plan. If you wan't it in FPC RTL then it

will became part of sparta packages in Lazarus. The current stalemate is blocking my job. Any predictable timeline? If it will take you another year ot two, then better solution is putting it in components/sparta.

Even if I'd add them now it would be at least half a year for them to appear in a stable release if we merge them to fixes_3_0 (which is not a given!). And if not it would probably be at least 2 years till the next major release.

Regards,
Sven

Tomas,

Alright. So what is the authorship of the default units and how does it fit to Delphi compatibility?

At some point (soon) I hope Free Pascal and Lazarus will expand beyond being Delphi compatible. In my recommendations I did not mean to infer that Delphi compatibility should be broken or removed, but that new units or even a new library can be added to Free Pascal or Lazarus which could be considered a new "Core" set of Pascal libraries. This "Core" library would offer a much improved Pascal coding experience with extensions to intrinsic types like string or array or integer.

I posted on these lists previously about my very quick string library, both in terms of execution speed and also in ease of use. The string type helper extensions I've written make tasks like parse test or html relatively ease with functions like FirstOf, SecondOf, LastOf, BeginsWith, EndsWith, Contains, Split, Join, and so on. I also make good use of implicit conversions in both my Array<T> and ArrayList<T> types as well as in the Networking area.

So to answer that question, my proposal would not impact migrating from Delphi to Lazarus, nor would it prevent you from using theses Core libraries in Delphi (as long as the languages are the same).

Nobody prevents vendors to use their namespace now, right?

Dotted namespaces weren't supported officially by FPC until two months ago with the release of FPC 3.0. And it wasn't until recently that most of the code tools and documentation issues with dotted namespace units were fixed. I sent a patch just this month to fix allow for dotted names in the documentation tool chain. Now that we're a few months past that point I think we should look towards integrating them, and that is why I am raising this subject now and not one year ago.

You're kind of making my point, and that is some units and the functions in them are reserved for Delphi compatibility. Great, we can have Delphi compatibility, but for added on specific functionality it should probably be noted as such "Core.Text". And this makes it very plain, if the code is going to be original to and to be maintained by the Free Pascal team members, then "Core.Text" is where all string related functions would go. If you need something a bit more specific, then it goes under that, for example "Core.Text.Encoding". This addresses the problem of "where does this function I wrote go" much better than the current system we have (SysUtils, StrUtil, LCLProc, LazUTF8).

Okay so what I am saying is clean it up, which is where you're going there with centrally managed. The hub is "Core" and things go under that like Networking, Graphics, Files, Text and so on. If anyone write a function that checks for something having to do with the a file, like a funtion FileCompare, then it goes somewhere under "Core.Files". It actually make picking units to put stuff in easier.

Sven Barth wrote

As long as it's not in the bootstrapping RTL I don't really care where we put it ;)

So it could be added to FPC trunk soon?
This issue has been open for a long time. I hope some decision can be made.

I don't understand many things around FPC's generics. I hope to learn more. For example, fcl-stl is not Delphi compatible yet FPC project otherwise provides Delphi compatible libraries.
Maciej's Generics.Collections is more compatible with Delphi. To me it looks like a good match for FPC.
Are there technical reasons against Delphi compatibility? Can I find information about this issue somewhere?

One more thing:
Anthony, please don't hijack Maciej's generics thread for your dotted namespace issue.
You can open another thread for it. Maciej's question is important and I want to follow its discussion.

Juha

2016-01-27 11:26 GMT+01:00 Sven Barth :

so what should I do? :)

2016-01-27 11:28 GMT+01:00 Juha Manninen :

Are there technical reasons against Delphi compatibility? Can I find information about this issue somewhere?

about compatibility and bugs:

https://github.com/dathox/generics.collections/raw/master/GenericsCompatibilityMatrix.pdf

Maciej,

Wouldn't it be possible to take my idea and start developing a new library which contains the generic containers you need? I have a nice generic container unit you could use or just pull out the classes you need out of the existing FPC generics unit, duplicate them in their your own unit, and ship that unit separately.

"Maciej Izak" wrote

2016-01-27 11:26 GMT+01:00 Sven Barth : > > Even if I'd add them now it would be at least half a year for them to

appear in a stable release if we merge them to fixes_3_0 (which is not a given!). And if not it would probably be at least 2 years till the next major release.

so what should I do? :)

If you want to use them *now* you should put them into components/sparta, though then again they only work with trunk anyway because of that one bug... It's not easy -.-

Regards,
Sven

"Anthony Walter" wrote

Maciej, Wouldn't it be possible to take my idea and start developing a new

library which contains the generic containers you need? I have a nice generic container unit you could use or just pull out the classes you need out of the existing FPC generics unit, duplicate them in their your own unit, and ship that unit separately.

He already *has* a working generic containers library that additionally is Delphi compatible. This discussion is about including it in FPC.

Regards,
Sven

Maciej Izak wrote

about compatibility and bugs: https://github.com/dathox/generics.collections/raw/master/GenericsCompatibilityMatrix.pdf

Yes, that is about your Generics.Collections compatibility. I was more interested why fcl-stl is not Delphi compatible while many other libraries provided by FPC project are.
This may be a dummy question, I may not know enough about generics.

Juha

2016-01-27 11:38 GMT+01:00 Sven Barth :

If you want to use them *now* you should put them into components/sparta, though then again they only work with trunk anyway because of that one bug... It's not easy -.-

Half of year sounds reasonable. I can wait. 2 years delay is too long. Btw. we need to remember about merging r31911 into fixes_3_0

It was donated by someone early on during the implementation of generics. I don't think the comparable Delphi units existed at the time. I think the implementation was more based on C++ templates/generics than on comparable C# or Delphi functionality (hence the name stl: Standard Template Library).

Michael.

2016-01-27 12:07 GMT+01:00 Michael Van Canneyt :

Delphi Generics.Collections exist since Delphi 2009. fpc-stl was introduced around 2012

FPC generics implementation was very buggy, was almost impossible to implement compatible version, and there was lack of Generics.Defaults comparable functionality (which is base for any collection - especially _LookupVtableInfo function). More info about _LookupVtableInfo :

http://stackoverflow.com/questions/17951412/what-does-the-default-tarray-sort-comparator-actually-do-and-when-would-you-use

Development process of Generics.* takes almost 2-3 years (most of time takes to create bug reports and finding workarounds... Even now I have a lot of not reported generics bugs). Without Sven cooperation whole investments would be impossible :).

2016-01-27 11:36 GMT+01:00 Anthony Walter :

Wouldn't it be possible to take my idea and start developing a new library which contains the generic containers you need?

As Sven said. All is ready. Anyway I like the idea of new namespaces more C# like (or even new namespaces should be compatible with well designed C# library). But this is subject for another thread.

What is the difference from CoreText or (not my choice) Core_Text? Can I do this
uses

   Core.Text;

instead of

uses
   Core.Text.Parser, Core.Text.XML, Core.Text.json, Core.Text.UTF8;

IF not then I'm against using dots in filenames, there is no value in dots when camel case does the same job with less typing.

as we are on the theme of "not do" also consider removing the fp prefix from all rtl functions and through away the ridiculous use of inc file instead of pas.

It appeared in FPC svn only in 2011. But fcl-stl was around earlier than that.

The idea was not Delphi compatibility. We want delphi compatibility, but at the same time don't want to discourage "competing" or "complimentary" contributions.

Michael.

y

To be absolutely 100% clear (so as not to put people off):

I don't mind/oppose addressing this with a solution that uses namespaces.

I just don't think it is an argument for the use of the latter.

Sometimes the distinction gets lost in the debate, so it merited a clarification :)

Michael.

In our previous episode, Michael Van Canneyt said:

True, and based on FPC generics principles that are also more C++ like.

Maciej Izak wrote

http://stackoverflow.com/questions/17951412/what-does-the-default-tarray-sort-comparator-actually-do-and-when-would-you-use

The Delphi code listed there looks implementation specific, too, although I don't understand many details.

    pinfo := @VtableInfo[intf, info^.Kind];
    Result := pinfo^.Data;
    if ifSelector in pinfo^.Flags then
      Result := TTypeInfoSelector(Result)(info, size);
    if ifVariableSize in pinfo^.Flags then
      Result := MakeInstance(Result, size);

Development process of Generics.* takes almost 2-3 years (most of time takes to create bug reports and finding workarounds... Even now I have a lot of not reported generics bugs). Without Sven cooperation whole investments would be impossible :).

Wow, it is a big task!
Anyway my common sense says that it can now be included in FPC trunk as a package (not part of RTL).
In the worst case scenario only Generics.Collections lib breaks when compiler internals change, and then Maciej will fix it. A temporary copy is needed anyway in Lazarus sources, as Ondrej wrote. We did the same thing with AdvancedIPC.
If the temporary copy works with FPC 3.0, then it can be used in Lazarus IDE sources sooner.
If FPC trunk features are required, then it will take rather long.

Juha

Yes, you explained the motive... But we can't be more organized now? The major problem, for me, not is because we don't use 'dots' in unit names but the names chosen itself.
For example: Lazarus has LCLProcs, LazUTF8. Why haven't added "Laz" every unit? Lazarus.Text.Encoding is a beautiful name... but just using LazTextEncoding, LazTextUTF8 do the same.

My problem are the names, not the 'design' them.

My 2 cents...

Marcos Douglas

Using your examples names -- I say that because I disagree they are good names:

Core.File.Utils
- ExtractFilePath
- ExtractFileName

These functions 'belong' to the file context, not strings.

Best regards,
Marcos Douglas

In our previous episode, Maciej Izak said:

FPC/Delphi seek their files in a fundamentally different way then C# and Java, which store their files (or maintain a database) hierachically per namespace.

It would be a massive undertaking and incompatible with everything before.

In our previous episode, Marcos Douglas said:

Well, they are FPC only, and only work for OSes with a filesystems, so

fpc.core.filesystem.file.utils is better I think.

At the very least FPC specific functionality should not rest in a very common worth as "core" as root prefix. That defeats the prime reason for namespace, avoiding clashes.

Marco van de Voort wrote

fpc.core.filesystem.file.utils is better I think.

+1 :D

Ondrej

FPC doesn't need to have "fpc" prefix because the compiler is the mainstream. "Core" is not good.
Maybe: system.file.utils

I don't like "utils". I'm just using the same names...

At the very least FPC specific functionality should not rest in a very common worth as "core" as root prefix. That defeats the prime reason for namespace, avoiding clashes.

I agree.
As I said before, I desagree with these names... but Michael said they are only examples.

Best,
Marcos Douglas

On Wed, Jan 27, 2016 at 6:22 AM, Michael Van Canneyt <

wrote:

[...]

ExtractFilePath/ExtractFileName sounds more related to file operations, so:

Core.File:
...
TFile = class sealed(TObject)

  public
    class function ExtractPath ... ; static;
    class function ExtractName ... ; static;

...

writeln(TFile.ExtractPath(...));
writeln(TFile.ExtractName(...));

or:

Core.File:
...
function ExtractPath ...;
function ExtractName ...;
writeln(File.ExtractPath(...));
writeln(File.ExtractName(...));

(btw the example above needs the -NS feature)

IMHO, if the <context> already is called "file", you don't need to add the context name again in the function name, so instead of:

writeln(Extract<File>Path(...));
writeln(Extract<File>Path(...));

just use:

writeln(<File>.ExtractPath(...));
writeln(<File>.ExtractName(...));

So, you can do <context>.code-completation to get all the features to this context.

Once more, the above is purely theoretical discussion; I am not opposing

anything, just pointing out that the use of namespaces is and remains a matter of preference (or even fashion/hype).

Both approaches compiles, but I agree the it is a preferencial thing.

Well, I disagree strongly:
I would put them in strings, since it is only about string manipulation.

That is my point: it depends on your starting position.

Michael.

Or:

System.File:
...
TUtils

  static methods for file utilities;

TFile
  static methods for file operations;

The fpc.core.filesystem.file.utils sounds just a dotted unit name, I can't see how it could help in something like a code-completation. :-/

Please guys....

You are completely missing the point. It is AN EXAMPLE.

The point was that namespaces do not solve the problem of where to put a routine and how to easily find it. I could probably find many other routines.

And the example replies I got make namespaces even less attractive to solve that particular problem !

Michael.

Exactly what I said in my first reply: 'core' is a poor choice for a first term.

Michael.

Hey guys ...

Now this Generics.Collections is completely hijacked by a namespace discussion. Does it mean the original issue is again buried and forgotten for another year or two?

You could easily move the unrelated discussion to another thread by indicating this thread in the subject, like:
"Dotted namespace used by FPC libs (was: Generics.Collections...)" or similar.

I was actually interested in the original Generics.Collections issue.

Juha

No. Sven is on it.

Michael.

2016-01-27 14:44 GMT+01:00 Michael Van Canneyt :

Anyway new thread for "Dotted namespace" is good idea :P

generics. I don't think the comparable Delphi units existed at the time. I think the implementation was more based on C++ templates/generics than on comparable

> C# or Delphi functionality (hence the name stl: Standard Template

Library).

Delphi Generics.Collections exist since Delphi 2009. fpc-stl was

introduced around 2012

FPC generics implementation was very buggy, was almost impossible to

implement compatible version, and there was lack of Generics.Defaults comparable functionality (which is base for any collection - especially _LookupVtableInfo function). More info about _LookupVtableInfo :

http://stackoverflow.com/questions/17951412/what-does-the-default-tarray-sort-comparator-actually-do-and-when-would-you-use

Thank you for the link, because now I know what was *really* bugging me about the code all the time (you know that feeling that you instinctively know that something is wrong, but you can't really pinpoint.it? ;) ). The point is that it is not necessarily guaranteed on each and every platform that the parameter passing of a (interface) method is the same as for a global function with an additional instance parameter. This *might* be true for those platforms on which Windows runs and thus we need to correctly support COM interfaces, but on other platforms this *could* be completely different (e.g. a platform could pass the instance in a register instead of the stack while normal functions get all their parameters from the stack; this would totally mess up the parameters that the functions expects). And *this* is something I don't want to deal with as this could potentially break every time we improve or fix something in the parameter passing code and then only for specific platforms...

So if you would instead change the code to use real class instances that implement the interfaces (they can be lazily allocated singletons or so) then I'd definitely be inclined to include the code in trunk.

And before you say that Delphi does it differently: the Delphi developers only have to maintain the code for 3 platforms (i386, x86_64 and ARM), we however have more to maintain and thus the chances for breakage are higher.

Regards,
Sven

In our previous episode, Sven Barth said:

So if you would instead change the code to use real class instances that implement the interfaces (they can be lazily allocated singletons or so) then I'd definitely be inclined to include the code in trunk.

Is there any hope for 3.0.2 ?

Thanks Sven,

I am glad there is a solution, I was afraid there would not be one, and then we'd be caught in some kind of stalemate :-)

Michael.

2016-01-27 15:03 GMT+01:00 Sven Barth :

Thank you for the link, because now I know what was *really* bugging me about the code all the time (you know that feeling that you instinctively know that something is wrong, but you can't really pinpoint.it? ;) ).

I have those feeling half of my life as programmer >.<

We need to somehow clarify many things in this field. My next big milestone is RTTI.Invoke method (I'd like to omit implementing this :P). For example only in FPC dyn. array parameter is passed on stack instead of by reference (in opposition to Delphi)... with small change in r30870 for register calling convention (changed for properties). Ofc. is possible to use constref modifier but... Arghhhh...

To implement this addition would be nice to fix this bug: http://bugs.freepascal.org/view.php?id=29245
Currently any class var (precisely "managed var" kind, like dyn array or interface) allocated in class constructor is released before class destructor.

And before you say that Delphi does it differently: the Delphi developers only have to maintain the code for 3 platforms (i386, x86_64 and ARM), we however have more to maintain and thus the chances for breakage are higher.

Life of FPC developer is so painful and happy at the same time...

Guys 3 observations.

1) if dots do not allow me to do something along the lines of Uses

     Core.Text;
   Instead of
   Uses
     Core.Text, Core.TExt.XML, core.Text.Json;
   Then I would prefer to avoid having to type the dots and stick to the

camel case unit names only, same effect in my book.

2) As the main distribution of fpc, you have the obligation to keep rtl and other libraries clean from any prefixes, the user's obligation is to make sure that his unit names to not conflict with the rtl not the other way around and since we are on the same subject clean up the fpXXX functions as well it breaks conformity.

3) Are you really going to introduce a 3rd (if memory serves me right) generics lib in the mix? Clean up guys the rtl must not have any duplicates it must have one and only one implementation, extra libraries can always be shared and if required installed by the user but not installed by default my disk space is not your playground.

Just food for thought I hope.

2016-01-27 15:03 GMT+01:00 Sven Barth :

FPC Generics.Default implementation is a little different than Delphi implementation. There is no global function with additional instance/self parameter, so I think the problem don't affect Generics.Defaults and i don't need to change anything.

All is passed as "true" self parameter, there is no fake or trick :P.

All is achieved by "class function" method syntax, which always has "self" parameter.

"Maciej Izak" wrote

> The point is that it is not necessarily guaranteed on each and every

platform that the parameter passing of a (interface) method is the same as for a global function with an additional instance parameter. This *might* be true for those platforms on which Windows runs and thus we need to correctly support COM interfaces, but on other platforms this *could* be completely different (e.g. a platform could pass the instance in a register instead of the stack while normal functions get all their parameters from the stack; this would totally mess up the parameters that the functions expects).

We need to somehow clarify many things in this field. My next big

milestone is RTTI.Invoke method (I'd like to omit implementing this :P). For example only in FPC dyn. array parameter is passed on stack instead of by reference (in opposition to Delphi)... with small change in r30870 for register calling convention (changed for properties). Ofc. is possible to use constref modifier but... Arghhhh...

The interesting thing about Invoke() will be support on other platforms ;) We've not yet decided how we'll tackle it...

Dynamic arrays were changed to be passed on stack in 2.7.1 on purpose AFAIK.

Regards,
Sven

"Maciej Izak" wrote

2016-01-27 15:03 GMT+01:00 Sven Barth : > > The point is that it is not necessarily guaranteed on each and every

platform that the parameter passing of a (interface) method is the same as for a global function with an additional instance parameter. This *might* be true for those platforms on which Windows runs and thus we need to correctly support COM interfaces, but on other platforms this *could* be completely different (e.g. a platform could pass the instance in a register instead of the stack while normal functions get all their parameters from the stack; this would totally mess up the parameters that the functions expects).

> > So if you would instead change the code to use real class instances that

implement the interfaces (they can be lazily allocated singletons or so) then I'd definitely be inclined to include the code in trunk.

FPC Generics.Default implementation is a little different than Delphi

implementation. There is no global function with additional instance/self parameter, so I think the problem don't affect Generics.Defaults and i don't need to change anything.

All is passed as "true" self parameter, there is no fake or trick :P. All is achieved by "class function" method syntax, which always has

"self" parameter.

I'll need to look at your code again, but even for class functions the same rules (and worries) as for normal methods apply.

Regards,
Sven

2016-01-27 17:24 GMT+01:00 Sven Barth :

I'll need to look at your code again, but even for class functions the same rules (and worries) as for normal methods apply.

Unlike Delphi, we have TCompare class and TEquals class, which is used for manual interfaces (together with TRawInterface and TComTypeSizeInterface). Additionally (unlike in Delphi which has hidden regular functions for this in implementation section with fake self parameter) TCompare and TEquals can be used in custom comparers.

don't worry :)

++ 1 !

Unlike Delphi, we have TCompare class and TEquals class, which is used for manual interfaces (together with TRawInterface and

TComTypeSizeInterface).

Additionally (unlike in Delphi which has hidden regular functions for

this in

implementation section with fake self parameter) TCompare and TEquals can be used in custom comparers.

I've just like to point out that with Svens new support for generic functions, we actually have template like functionality in Free Pascal. You can now write functions which will verify at compile time the support of a method or operator for a particular type. This somewhat obviates the need to register or pass compare or equal functions or interfaces.

For example, you can now write a in a type "TArray<T> = array of T" sorting implementation:

procedure Sort<T>(var Items: TArray<T>);
var
  A, B: T;
  I: Integer;
begin
  for I := Low(Items) to High(Items) - 1 do
  begin
    A := Items[I];
    B := Items[I + 1];
    if A > B then
    begin
     Items[I] := B;
     Items[I + 1] := A;
    end;
  end;
end;

Obviously this is a terribly inefficient sorting algorithm, but it demonstrates the feature clearly. The condition "if A > B then" will be cause the compiler to verify at compile time whether or not the T being used support comparison through the "<" operator. The same kind of support extends to the "=" operator as well.

If you using symbols are unclear, the above routine could be altered to use a CompareTo method. For example:

  if A.CompareTo(B) < 0 then

This would then cause the compiler to check the type B for a CompareTo function with the appropriate signature. This can then be paired with type helpers to add CompareTo methods to any type including the intrinsic ones.

Just so you know ...

2016-01-27 21:01 GMT+01:00 Anthony Walter :

You don't need to pass any compare nor equal functions in the Generics.Collections.
Mentioned in your post kind of usage of operators was possible long before "new generic functions":

class procedure TGArray<T>.Sort(var Items: TArray<T>);
{ ... identical code here ...}

In previous version of Generics.Collections library was possible to use two kinds of all collections (one kind with operators and one kind with manual interfaces) for example : TFastList (with operators verified at compile time) and TList (more Delphi compatible with manual interfaces). Approach with operators is weak in many points:

* is not much faster than manual interfaces (it is even slower in many cases (!), that was shock for me)
* low level of encapsulation
* lack of support for more advanced collections (for example with usage of cuckoo hashing)
* you need to define operators for all non trivial types (and that is not always possible in simple way, for example: external library)
* Delphi/C# incompatible way of handling collections
* is harder for customization (case sensitive/insensitive)
* MOST IMPORTANT: it is only friendly for author of those collections, for daily user it is hell - especially for advanced collections like "dictionary/hashmap"

fpc-stl is implemented with usage of operators. look below (just declaration example, problems with usage of operators grows exponentially :).

Example code for Generics.Collections:

=== code begin ===
type
  TRec = record
    ID1, ID2: Int64;
  end;
var
  d1: THashMap<TRec, TSome1>;
  d2: THashMap<string, TSome2>;
  d3: THashMap<Int64, TSome3>;
=== code end ===

fpc-stl equivalent:

=== reduced (!) code example begin ===
type
  TRec = record
    ID1, ID2: Int64;
    class operator Equal(a: TRec; b: TRec) : Boolean;
  end;
class operator TRec.Equal(a: TRec; b: TRec) : Boolean;
begin
  Result := (a.ID1 = b.ID1) and (a.ID2 = b.ID2);
end;
type
  THash_TRec = record
    class function Hash(A: TObject; B: SizeUInt): SizeUInt; static;
  end;
  THash_String = record
    class function Hash(A: string; B: SizeUInt): SizeUInt; static;
  end;
  THash_Int64 = record
    class function Hash(A: Int64; B: SizeUInt): SizeUInt; static;
  end;
class function THash_TRec.Hash(A: TObject; B: SizeUInt): SizeUInt;
begin
   {
   some hash function for TRec... you need to provide
   }
end;
class function THash_String.Hash(A: TObject; B: SizeUInt): SizeUInt;
begin
   {
   some hash function for string ... you need to provide
   }
end;
class function THash_Int64.Hash(A: TObject; B: SizeUInt): SizeUInt;
begin
   {
   some hash function for Int64 ... you need to provide
   }
end;
d1: THashmap<TRec, TSome1, THash_TRec>;
d2: THashmap<string, TSome2, THash_String>;
d2: THashmap<Int64, TSome3, THash_Int64>;
=== code end ===

2016-01-27 17:24 GMT+01:00 Sven Barth :

I'll need to look at your code again, but even for class functions the same rules (and worries) as for normal methods apply.

I hope that your research in Generics.Defaults will be successful for manual interfaces :P

Most important about manual interfaces, and why can't be used any other solution without painful consequences:

1. we don't want to use ARC interfaces (for singletons created at startup in Generics.Defaults)
side note: in Generics.Defaults is introduced TSingletonImplementation for non ARC COM interfaces

2. even if point 1. is simple to achieve, it brings a lot of problems because we need to keep somewhere our singletons and that means:

SIGSEGV exception is guaranteed, during closing application in many scenarios

program X;
uses
  A, B;
begin end.

A source code:

unit A; interface uses Contnrs;
  var GarbageCollector: Contnrs.TObjectList;
implementation initialization
  GarbageCollector := Contnrs.TObjectList.Create(true);
finalization
  GarbageCollector.Free;
end.

in B is used A and Generics.Collections.

unit B; interface uses A, Generics.Collections; implementation
begin
  GarbageCollector.Add(TDictionary.Create);
end.

Generics.Collections (which is using Generics.Defaults) and our Generics.Defaults is released before A. It will cause a memory violation in Generics.Defaults for our singleton O__o.

To avoid this memory violation is necessary to omit point 1.

3. To avoid memory violation, any instance of collection should be owner of instance of IComparer / IEqualityComparer and that is performance and memory killer in comparison to manual interfaces.

"Maciej Izak" wrote

2016-01-27 17:24 GMT+01:00 Sven Barth : > > I'll need to look at your code again, but even for class functions the

same rules (and worries) as for normal methods apply.

I hope that your research in Generics.Defaults will be successful for

manual interfaces :P

Most important about manual interfaces, and why can't be used any other

solution without painful consequences:

1. we don't want to use ARC interfaces (for singletons created at startup

in Generics.Defaults)

side note: in Generics.Defaults is introduced TSingletonImplementation

for non ARC COM interfaces

Why not? This would solve the whole problem below. Also you can create them lazily, so not every instance would need to be available from the start on...

2. even if point 1. is simple to achieve, it brings a lot of problems

because we need to keep somewhere our singletons and that means:

SIGSEGV exception is guaranteed, during closing application in many

scenarios

Generics.Defaults is released before A. It will cause a memory violation in Generics.Defaults for our singleton O__o.

To avoid this memory violation is necessary to omit point 1. 3. To avoid memory violation, any instance of collection should be owner

of instance of IComparer / IEqualityComparer and that is performance and memory killer in comparison to manual interfaces.

Why would each collection instance need to contain an instance of the comparer? They don't contain state and are reentrant, so they can be easily shared with ARC singletons.

Note: there would either need to be a global variable for each instance or a list that gets automatically finalized as well (e.g. as a stupid implementation an array of IInterface). Then if Generics.Defaults is finalized before the other unit using it only the reference count will be decreased and only when the other unit is finalized the comparer will be destroyed.

Regards,
Sven

2016-01-28 0:38 GMT+01:00 Sven Barth :

Yes it can be done in that way, but I want to avoid this (It will complicate other things). In Generics.Defaults manual interfaces are easier to maintain. Manual interfaces are more solid construction. They are more resistant for improper use than regular ARC interfaces. You did not specify any technical argument to discrediting manual interfaces implementation in Generics.Defaults. Just a feeling :P. Your only technical argument has been overthrown.

camel case unit names only, same effect in my book.

Dotted unit names allow you to omit prefixes if they have been passed on the commandline (Delphi allows this, FPC not yet however). E.g. you'd be able to write "uses Text, Text.Xml, Text.Json" if "Core" is passed on the commandline as namespace to search in.

2) As the main distribution of fpc, you have the obligation to keep rtl

and other libraries clean from any prefixes, the user's obligation is to make sure that his unit names to not conflict with the rtl not the other way around and since we are on the same subject clean up the fpXXX functions as well it breaks conformity.

The problem is when we introduce a new unit with a logical, fitting name that then conflicts with a unit a user already had. And why should we clean up the fpXXX function? I don't get what you're hinting at.

3) Are you really going to introduce a 3rd (if memory serves me right)

generics lib in the mix? Clean up guys the rtl must not have any duplicates it must have one and only one implementation, extra libraries can always be shared and if required installed by the user but not installed by default my disk space is not your playground.

This third generics library is a Delphi compatible one so that's a big plus. The others must stay for backwards compatibility (also fgl is a nice test durog cycling the compiler that nothing basic was broken with generics; one of the main reason it's still in rtl and not rtl-objpas or rtl-extra).

Regards,
Sven

"Maciej Izak" wrote

2016-01-28 0:38 GMT+01:00 Sven Barth : > > Why would each collection instance need to contain an instance of the

comparer? They don't contain state and are reentrant, so they can be easily shared with ARC singletons.

> > Note: there would either need to be a global variable for each instance

or a list that gets automatically finalized as well (e.g. as a stupid implementation an array of IInterface). Then if Generics.Defaults is finalized before the other unit using it only the reference count will be decreased and only when the other unit is finalized the comparer will be destroyed.

Yes it can be done in that way, but I want to avoid this (It will

complicate other things). In Generics.Defaults manual interfaces are easier to maintain. Manual interfaces are more solid construction. They are more resistant for improper use than regular ARC interfaces. You did not specify any technical argument to discrediting manual interfaces implementation in Generics.Defaults. Just a feeling :P. Your only technical argument has been overthrown.

The format of interface VMTs could also differ per platform so considering that as more stable only holds true because of what we currently support.

The more stable approach would definitely be the one that does not rely on implementation details, but only on the specified, documented language behavior (bugs not withstanding of course), thus the approach I've mentioned above.

I consider the approach with manual interfaces as hackish. Period.

Nevertheless if I don't find anything else that sparks my worries I'll probably commit it anyway... However on the first sign of a breakage (in the part that's related to the manual interfaces) that's not because of a newly introduced bug I'll disable them and won't care about them anymore.

Speaking of breakage... Do you have tests that could be run together with our testsuite? They need to be named t*.pp and need to return an error code of 0 on success and anything else on error. They can make use of fpcunit AFAIK.

Regards,
Sven

2016-01-28 11:34 GMT+01:00 Sven Barth :

The format of interface VMTs could also differ per platform so considering that as more stable only holds true because of what we currently support.

That is very easy to adjust.

To be clear maybe is time to documenting this.

There is one big advantage in manual interfaces - less RTTI trash. Other approach will potentially brings ~100 additional useless classes or even more, It depends on the manner of implementation (for example is possible 100 classes per hashing or (!) even more - it can potentially mean few thousands useless classes). Maybe is possible to reduce this by using "implements" keyword or by this language feature (redirecting interface method implementation to other method): "function IFoo.Foo = SomeOtherNameThanFoo"

(!!!) I don't know whether a different approach is implementable (especially because we have multi hashing, on the other hand in few places generics relations are complicated). If we decide to use other approach (if it is possible) than manual interfaces, it will brings other hack IMO much more "hackish" (fake interface casting) and it potentially/additionally can generate many trash classes.

I have inner tests especially for dictionaries (thanks to FPC generics we have many kinds of dictionaries :O). I will adjust the tests when you decide to commit library.

Maciej Izak wrote on Thu, 28 Jan 2016:

No. The reason for it to be an undocumentated implementation detail is exactly so that we can change it or implement it differently when necessary. The compiler supports a particular programming language, not a particular binary representation/implementation of certain programming language constructs.

Jonas

Although I see the benefit of this I do not see me using it. my goal is to avoid the command line and minimize typing as much as possible with out loosing functionality.

The problem is when we introduce a new unit with a logical, fitting name that then conflicts with a unit a user already had. And why should we clean up the fpXXX function? I don't get what you're hinting at.

That is not the fpc team's responsibility. Keep it clean, keep it simple, keep it easy to learn. Any external library will have to do what ever it can to avoid those kind of problems in most cases the easiest way is to prefix the units with a company/author 3 or 4 letter prefix or in the case of dotted unit names a complete namespace.

As for the FPxxxx functions, same clean up group, no prefix for the main distribution. Not in the unit names and especially not for the function names. That is something the 3rd party library developers do and they do not need any competition from fpc.

Keep the new, drop the old or merge. if fgl is good for the compiler then keep it as a unit testing and share it for existing users. I do not think that it needs to be part of the main installation. The fgl user base, I believe, already knows how to download and install external dependencies. At least make it an opt in/out in the installer while the new is part of the required packages and fgl is not auto installed.

As always only observations and my own "successful" practices. Your tool your choice.

PS
Keep in mind that I already have around 20 classes based on fgl unit, so if the changes above are to happen it will take me around a week changing the code to the new generics and retesting everything. If I had more than that I would probably expect some sort of

On Thu, Jan 28, 2016 at 7:34 AM, Sven Barth
wrote:
[...]

The format of interface VMTs could also differ per platform so considering that as more stable only holds true because of what we currently support.

Sorry for ask here, but, don't you recomment to use interfaces? I'm making a project and I'm planning to use some COM interfaces to make something a list adapter
<http://developer.android.com/reference/android/widget/ListAdapter.html>.

[...]

What is manual interfaces, does it mean CORBA interfaces?

I'm asking about using interfaces because I could easily change my project to use abstract classes, however I don't know if the interfaces choice can be a good choice.

"silvioprog" wrote

On Thu, Jan 28, 2016 at 7:34 AM, Sven Barth

[...] > The format of interface VMTs could also differ per platform so

considering that as more stable only holds true because of what we currently support.

Sorry for ask here, but, don't you recomment to use interfaces? I'm

making a project and I'm planning to use some COM interfaces to make something a list adapter.

As long as you don't pull stunts as Maciej here you don't have to worry :)

> > The more stable approach would definitely be the one that does not rely

on implementation details, but only on the specified, documented language behavior (bugs not withstanding of course), thus the approach I've mentioned above.

No. Corba interfaces are non-reference counted interfaces. Manual interfaces means that an interfaces VMT had been created by hand and passed around as an interface instance.

I'm asking about using interfaces because I could easily change my

project to use abstract classes, however I don't know if the interfaces choice can be a good choice.

There isn't that much difference in using interfaces or abstract classes. Only the reference counting of COM interfaces comes to mind and then you should avoid using the class instance instead of its interfaces.

Regards,
Sven

to avoid the command line and minimize typing as much as possible with out loosing functionality.

Lazarus usually picks up new commandline parameters rather fast. Especially ones like these.

keep it easy to learn. Any external library will have to do what ever it can to avoid those kind of problems in most cases the easiest way is to prefix the units with a company/author 3 or 4 letter prefix or in the case of dotted unit names a complete namespace.

As for the FPxxxx functions, same clean up group, no prefix for the main

distribution. Not in the unit names and especially not for the function names. That is something the 3rd party library developers do and they do not need any competition from fpc.

The FP prefixes for the generic types were introduced, because the compiler could not handle cross unit type overloads with generics correctly. Now they are part of backwards compatibility.

The fp prefixes for the Posix functions are there to avoid confusion with the native Pascal functionality (e.g. mkdir) and for consistency all these functions have the prefix.

keep it as a unit testing and share it for existing users. I do not think that it needs to be part of the main installation. The fgl user base, I believe, already knows how to download and install external dependencies. At least make it an opt in/out in the installer while the new is part of the required packages and fgl is not auto installed.

We go to great lengths to preserve backwards compatibility. So we won't simply drop a unit just because the one or other user can't handle more than one generic container library. Also the three libraries have different use cases. The one from Maciej is Delphi compatible and fast, but on the other hand comparatively heavy weight. The fcl-stl is more like the C++ STL in it's usage and more lightweight (also it supports functionality that fgl does not, like the TDeque). Fgl then is just a simple implementation of the containers. Just as lightweight, but slower and less feature rich than Generics.Collections.

Also you don't seem to have a clue how the building of the compiler works. I want to know of a breakage of the generics as soon as possible and that's only possible if the unit is part of the core RTL. Otherwise I could simply run the testsuite, which covers far more tests. But if I can't compile fgl already, why should I do a rebuild of all packages and a run of the testsuite... That's just a waste of time that I better spend fixing the bug.

TL;DR: The three libraries will stay as they are. Maybe fcl-stl will be moved to the fppkg based repository in the long term, but that's it.

Regards,
Sven

That's your prerogative, its a waste of time but its your time.

Also the three libraries have

Sure go ahead.

Also you don't seem to have a clue how the building of the compiler works.

No I don't and thankfully I don't need to learn.

I want to know of a breakage of the generics as soon as possible

and that's only possible if the unit is part of the core RTL.

I disagree but its not interesting enough to spend more time.

Otherwise

Yeah because rebuilding all the packages and running the complete suit is the only possible way to work.

TL;DR: The three libraries will stay as they are. Maybe fcl-stl will be moved to the fppkg based repository in the long term, but that's it.

Sure, your time go ahead have fun.

In our previous episode, Sven Barth said:

The fp prefixes for the Posix functions are there to avoid confusion with the native Pascal functionality (e.g. mkdir) and for consistency all these functions have the prefix.

(And most importantly "read", "write" and "close". Worse, read and write are not even functions but intrinsics, so they are available everywhere. And they are not defined as POSIX functions, but "loosely modelled after POSIX" :-))

In our previous episode, silvioprog said:

Interfaces are relatively slow. Not only because of the refcounting, but returning interfaces in a tight loop (e.g. to get the elements of an enumeration) would be a new allocation each time.

But even if you have small objects (max 3-5 methods and few attributes...) this overhead that you talk about be slow, is still considerable?

In other words, do you consider refcounting always slow in all cases?

Marcos Douglas

In our previous episode, Marcos Douglas said:

That overhead is not really dependent on the size of the object.

In other words, do you consider refcounting always slow in all cases?

No. Only for the most inner loops. But general container types should not have such limitations IMHO, which is why I use records in my container lib.

I don't see a reason for an iterator to be an interface anyway, since the usage should be fairly local.

A typical example where it might happen is in a collection of collections like a hash. You have a couple of buckets and needs a type for the bucket itself for the disambiguation. Those are fairly small collections in a good hash (since divided by hashsize), but there are lot of them (hashsize). Many of them will only contain one item.

Iterating over all elements then creates and destroys hashsize iterators then.

"Marco van de Voort" wrote

In our previous episode, silvioprog said: > > The format of interface VMTs could also differ per platform so

considering

> > that as more stable only holds true because of what we currently

support.

> > > Sorry for ask here, but, don't you recomment to use interfaces? I'm

making

> a project and I'm planning to use some COM interfaces to make something

a list

Note: the enumerator of a for-in is only fetched once before the loop, so it does not really matter whether it's an interface or record as long as the elements themselves aren't on demand allocated interfaces.

Regards,
Sven

"Marco van de Voort" wrote

In our previous episode, Sven Barth said: > The fp prefixes for the Posix functions are there to avoid confusion

with

> the native Pascal functionality (e.g. mkdir) and for consistency all

these

> functions have the prefix. (And most importantly "read", "write" and "close". Worse, read and write are not even functions but intrinsics, so they are available everywhere.

And

they are not defined as POSIX functions, but "loosely modelled after

POSIX"

:-))

Intrinsics are handled as belonging to the System unit. You can write System.Writeln for example and it will work
(which is why the IfThen() intrinsic wouldn't be a problem in that regard)

Regards,
Sven

Well, if an object is huge, more overhead to instantiate it.

> In other words, do you consider refcounting always slow in all cases? No. Only for the most inner loops. But general container types should not have such limitations IMHO, which is why I use records in my container lib.

I can agree with loops.
I didn't understand "container types"... you mean a "bucket of data"? Anyway, I will always prefer objects instead records.

Marcos Douglas

In our previous episode, Sven Barth said:

The trouble is that you then have to avoid for-in for many potentially small iterations as in the hash case.

On Fri, Jan 29, 2016 at 4:08 AM, Sven Barth
wrote:
[...]

Thxs for that info! :-)

Hm... I didn't know that.

I need to take a test using some profiling tool to check the real cost using interfaces, because in my case I'm using lists. However, I still can't understand why some programmers avoid to use interfaces in Pascal. :-/

Hm... that's my case. I have an object list that the key is an integer and the value is an object, ie a hash map.

However, some years ago I got a problem using interfaces in an old draft that I made, so to fix the problem I chose abstract class instead of interface. I don't know if it is a compiler behaviour or something that I forgot, the test is:

=== begin code ===

  ITest = interface
    ['{1DB8BD50-FCA2-40B3-B25B-A858DD206D26}']
    procedure SetTest(ATest: ITest);
  end;
  TTest1 = class(TInterfacedObject, ITest)
  private
    FTest: ITest;
  public
    procedure SetTest(ATest: ITest);
    property Test: ITest read FTest write FTest;
  end;
  TTest2 = class(TInterfacedObject, ITest)
  private
    FTest: ITest;
  public
    procedure SetTest(ATest: ITest);
    property Test: ITest read FTest write FTest;
  end;

...

procedure TTest1.SetTest(ATest: ITest);
begin
  FTest := ATest;
end;
procedure TTest2.SetTest(ATest: ITest);
begin
  FTest := ATest;
end;
procedure TForm1.Button1Click(Sender: TObject);
var
  VTest1, VTest2: ITest;
begin
  VTest1 := TTest1.Create;
  VTest2 := TTest1.Create;
  VTest1.SetTest(VTest2);
  VTest2.SetTest(VTest1);
end;

=== end code ===

It throws some memory leaks, so to fix the problem I used abstract class:

=== begin code ===

  TTest = class abstract
  public
    procedure SetTest(ATest: TTest); virtual; abstract;
  end;
  TTest1 = class(TTest)
  private
    FTest: TTest;
  public
    procedure SetTest(ATest: TTest); override;
    property Test: TTest read FTest write FTest;
  end;
  TTest2 = class(TTest)
  private
    FTest: TTest;
  public
    procedure SetTest(ATest: TTest); override;
    property Test: TTest read FTest write FTest;
  end;

...

procedure TTest1.SetTest(ATest: TTest);
begin
  FTest := ATest;
end;
procedure TTest2.SetTest(ATest: TTest);
begin
  FTest := ATest;
end;
procedure TForm1.Button1Click(Sender: TObject);
var
  VTest1, VTest2: TTest;
begin
  VTest1 := TTest1.Create;
  VTest2 := TTest1.Create;
  VTest1.SetTest(VTest2);
  VTest2.SetTest(VTest1);
  VTest1.Free;
  VTest2.Free;
end;

=== end code ===

However, I need to use the ARC feature in some occasions, and it seems that the better FPC entity that already implements that is the TInterfacedObject. :-/

Well, I did a simple test. Result:

C: 00:00:11.008
I: 00:00:14.555
I: 00:00:14.511
C: 00:00:10.880
Press [ENTER] to exit ...

Source: http://pastebin.com/x74V4gEx .

It seems that the COM interfaces is a little bit slower than classes. Anyway, I don't have problem to use interfaces, however I'll use it only when it is really necessary.

2016-02-03 3:53 GMT+01:00 silvioprog :

Well, I did a simple test. Result:

Note: this test has nothing to do with Generics.Collections library.

2016-01-27 13:39 GMT+01:00 Juha Manninen :

Generics.Collections is now in free-sparta branch (r51449). Should be merged with Lazarus trunk very soon.