David Heffernan

6 minutes ago, Lars Fosdal said:

Can you offer an example?

TList<T>

FWIW my codebase doesn't use the RTL generic collections. It uses a collections library that I wrote, that amongst other things has collection classes that allow access to items via references to the underlying records for exactly this situation.

I think that you are making valid points, but you aren't pinning the blame in quite the right place. I don't think the issue is with value types per se. To my mind the issues are more about limitations of the standard RTL collection classes.

27 minutes ago, Lars Fosdal said:

you must copy the entire record, modify it, and the copy it back

Not if you use a collection that provides you access to items via references to the underlying records

1 hour ago, Lars Fosdal said:

We also know that the two need to be handled differently when it comes to changing their contents.

That is correct. But that's not the point you made.

3 hours ago, Rollo62 said:

I really don't like to have  a  TStringListF for right file handling, a TStringListS for right stream handling, a TStringListKV for right Key/Value handling.

Files are a special case of streams. And they are orthogonal to collections of strings. A string list is the wrong class for key/value pairs. 

I don't think you need string list interposers for any of these things. 

19 minutes ago, Uwe Raabe said:

Design time packages can be a PITA when you often switch source code versions affecting those components. 

That's true of course, but the problem arises the moment you use a single third party component.

1 hour ago, Rollo62 said:

@David Heffernan

More trouble means I have to make all these components work in the designer now, I think there is no neat trick w/o registering them.

Also they are no more compatible classes, which could be used as "Xyz is TButton".

You just put them in a designtime package, install it, and then use them. That's what I do. I don't find it at all onerous.

7 minutes ago, Rollo62 said:

But what would be the alternative, to have a separate layer of self-defined components, on top of the existing ones.

Yes.

7 minutes ago, Rollo62 said:

That would basically do the same job as the interposers, but would cause a LOT more trouble in designing the forms.

No, it's no trouble at all.

This is the SO post:

https://stackoverflow.com/questions/63823156/using-delphis-trichedit-is-there-a-way-to-set-up-a-link-so-someone-can-click

I can comment Remy's answer in the dupe, which I am using to good effect:

https://stackoverflow.com/a/42536393/505088

2 hours ago, Lars Fosdal said:

Start a new topic.

Give some examples.

We don't need a topic or any examples. We all know that records can be used as generic types. 

1 hour ago, Lars Fosdal said:

Another benefit of using generic classes over records is the amount of reuse.

You can use records and classes with generics.

5 minutes ago, Lars Fosdal said:

TList<^TDataRec>? 

Really? How are the records allocated? And if you could do that, why couldn't you do exactly the same with a dictionary.

Which is my original point. If you can't use a dictionary with records, then I don't see that you can use any collection with records.

32 minutes ago, Lars Fosdal said:

Which is why I don't use dictionaries with records. It is rare that I load up a dictionary and do not need to change some of the content later.
If I was insistent on doing records, I would probably write code that ordered the array by the key and did binary lookup to a pointer to the record.

How is it any different from holding them in TList<T>?

It depends on how you want to access the data. This isn't really related to associate array style access by key. The issues with value types and copying apply equally to all containers.

1 hour ago, Lars Fosdal said:

but I don't use them with records, only objects

Why not?

1 hour ago, Lars Fosdal said:

What is the best container for random lookup access for records?

Surely the answer is the same as for objects. If you use a dictionary for objects, why not a dictionary for records?

This issue is covered explicitly by the documentation: http://docwiki.embarcadero.com/RADStudio/Sydney/en/Structured_Types_(Delphi)#Dynamic_Arrays

20 minutes ago, Mahdi Safsafi said:

Typically both produce the same output. Stefan code is based on template. Mine is not. I found my code more readable and friendly for typing (you don't need to worry about <>). But its just a taste of manner.

But your code can only be used for arrays of byte. Stefan is demonstrating generic code. 

1 hour ago, Mahdi Safsafi said:

There is another way without specifying explicitly the generic type param and it generates the same output. Internally slice requires dst(open array type), src(pointer type) and of course a count(integer type). It uses src to get the pointer and dst info to compute the offset meaning you can provide a fake declaration for the source:

 type TOpenArray = array[0 .. 0] of Byte;
 POpenArray  = ^TOpenArray ;
 MergeSort(Slice(POpenArray(@values[mid])^, len - mid));

 

What does this offer over what Stefan posted in his article? 

I'd be surprised if converting from VCL to FMX was simple enough to be usefully automated.

Why would there be conflicts in files that you have not modified? My advice to you is that before you try to change the process to fix the problem, you make sure that you have fully diagnosed the problem. 

If you are not working in A, B and C then you simply should never see any conflicts. My guess is that someone in your organisation is using git incorrectly. No reason at all that you should have any troubles with all this in a single repo. 

7 hours ago, David Schwartz said:

I think the repos should be set up on a per-project / import EXE / folder basis.

Oh. I took that to mean you want one repo for each of the 850 different variants. 

850 repos for every client specific variation sounds kinda crazy. I suspect that you aren't getting great feedback here because your organisation's work flow is, er, unique. 

14 minutes ago, Fr0sT.Brutal said:

If you care about performance so much, you can use

if Ord(c) in [Ord('A')..Ord('Z')]

or

case c of
  'A'..'Z': ...
end;

 

Read Andy's comments to my answer in the SO post.

If you care about performance, measure it. 

No reason to give any credence to that comment. Ignore it and move on. 

Be happy that your code is not limited to text that can be encoded with whatever ANSI locale the machine it runs on is using. 

Lightweight MREW sounds useful. One does wonder if it works, having experienced the monitor debacle.