That's what I fear, that having TStringList override and not inherite this method might change the behaviour of TStringList descendants which might rely on knowing that the actual method called will be TStrings.IndexOfName. So I still wonder, would implementing a method which wasn't previously overriden break compatibility with existing code?
Regarding testing, I heavily tested my modification with random name=key values, where there are duplicates, some strings are just 'name=' without the value or even 'name' only, and checked with different NameValueSeparators that sort before and after the generated random names. I generate the same random names and values for an original TStringList and my TStringListMod. Then I generate a batch of random names for searching, but about half of them are out of the original range so there are lots of searches for names which will not be found. Finally I run that batch of searches for each stringlist and store the values found in independent places, and after both searches have finished, I check that the values found are consistent between both stringlists. Pretty much I think I've covered every corner, including "what-if-the-searched-name-would-go-last", where Find returns false *and* an index out of the current stringlist.
Another thing is whether a certain implementation is just a bug, or it's a design decision to keep exactly the same Delphi behaviour. Imagine this scenario: a TStrings object, sorted, Duplicates set to dupIgnore, and with OwnsObjects = true. If you add a string with an object attached with AddObject(s, aobject), and the string already exists in the list (with an object attached), the object is simply overwritten without freeing it first. Supposedly one uses OwnsObjects to not care about freeing objects before destroying the stringlist. Again, this happens because TStringList doesn't override AddObject to take into account that objects shouldn't be overwritten that easily in the case of OwnsObjects = true.
Function TStrings.AddObject(const S: string; AObject: TObject): Integer;
begin
Result:=Add(S);
Objects[result]:=AObject;
end;
Of course TStrings knows nothing of OwnsObjects, but TStringList should have overriden that method so to check if OwnsObjects and there's an object there to free because it's going to be overwritten.
Maybe the path to go is to suggest these things to Embarcadero first, and if they ever implement it, FPC would follow them to match implementations. But maybe that's a path that FPC devs would think it's bad, because if Embarcadero changes its implementations, old code might break, and thus FPC old code might break as well.
That's why I'm going careful with this, to know before acting, and learn more before reporting at the bugtracker. Right now I just program as hobby, and I mainly use simple stuff like TStringList which is easy to deal with. I see some shortcomings with the current implementation of TStringList, at least in the way I want to use it, and I just want to know if the community in general could benefit from my ideas to overcome those limitations.
Recent
