David Heffernan

18 minutes ago, Tommi Prami said:

And find file from disk and the spot, sure diff to repo will help, but still, would be life saver when this happens. 

You are massively overstating this. Finding a file from disk is not difficult. Yes it takes a few seconds, but then it's not like this issue happens regularly. Every feature takes resources to implement. Given the immense problems that the entire Delphi product has, I for one would be disappointed if Emba spent resources on features like this that bring so little benefit.

53 minutes ago, Tommi Prami said:

Vote if you care : https://quality.embarcadero.com/browse/RSP-30991
IDE Could/Should open dfm in text form, if it/RLINK will find some problem with it. (and show the position in way or other)

 

-Tee-

Doesn't seem to me like this is a very significant problem given that you can just open the file in a text editor yourself.

6 minutes ago, Tommi Prami said:

Would be nice IDE would always convert binary to text, if there are one. Got hit by that this summer, there still was few binay dfm's in our repository.

Not sure the IDE should do that. There are tools to convert. If you want to convert, then use those tools. If the IDE did this automatically then that would be painful for people who wanted to use binary.

8 minutes ago, toms said:

Convert it then?

https://stackoverflow.com/questions/3494554/delphi-form-dfm-to-text/3496617#3496617

If it is in binary form then presumably there would be no need because there would be no problem in it

1 hour ago, Fr0sT.Brutal said:

Ah yes right I haven't noticed the getter returning pointer to array item. In my record list class I use dynamically allocated records and store pointers only so have no such issues.

Well, you avoid some of the issues, but not all. For instance you don't avoid the issue where an item is deleted, but a stale pointer is retained. Additionally you end up with a large number of heap allocations, and memory that can be scattered which can impact performance.

1 hour ago, Uwe Raabe said:

If I got that right, Stefan is referring to the case where the array is relocated, which invalidates the record pointers. This is not the case for a class list, where only pointers to the class instances are stored inside the array. Relocating such an array will keep the instance pointers intact.

Granted the indirection that is offered by a reference type does make some of the issues hard to trip over, but they still exist.

1 hour ago, Stefan Glienke said:

Nope - with classes you are dealing with reference types - in this case you are pointing to a location inside the dynamic array being used as storage inside the list - any reallocation can change that.

In a collection which owns its members then removing an item leads to a stale reference in either scenario (classes vs records). 

55 minutes ago, Remy Lebeau said:

The RTL's generic TList<T> does not provide access to elements by reference, only by value.  At least for its Items[] property.  Its List property gives you access to the underlying dynamic array, so you can access the elements directly.

 

Your third sentence directly contradicts the first sentence. 

14 minutes ago, Stefan Glienke said:

And there the trouble starts - why on earth should the byref property be writeable.

Yes, this should be a read only property.

In an ideal world we'd have proper language support for references, as I think is especially we done in D

foreach (ref elem; arr) {
    elem = 0;
}

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.