TdwsConfiguration, property class

[GoogleCodeExporter]

I noticed in the Object Inspector, that one property TdwsConfiguration class 
has probably incorrect type:

TdwsConfiguration = class(TPersistent)
<...>
published
property Conditionals : TStringList read FConditionals write SetConditionals;
property ScriptPaths : TStrings read FScriptPaths write SetScriptPaths;
<...>

Why Conditionals property has a TStringList type, not TStrings like ScriptPaths?

Original issue reported on code.google.com by jac....@gmail.com on 8 May 2013 at 4:29

[GoogleCodeExporter]

IIRC that was to give access to Sorted & Duplicates property which TStrings 
doesn't have.
ScriptPaths could probably use those as well in some circumstances.

What would be the issue for these not to be TStrings?

Original comment by zar...@gmail.com on 10 May 2013 at 6:04

• Changed state: NeedMoreInfo
• Added labels: Type-Other
• Removed labels: Type-Defect

[GoogleCodeExporter]

I mean the public interface of the class and "clean code". Inside, of course, 
TStringList is correct. But if in future you change the Conditionals type to 
e.g. TOtherStrings the remaining code will require changes. If the interface of 
the class was the type TStrings, and if inside was used TStringList then you 
could changed inside type to TOtherStrings without having to change the rest of 
the code (because public interface was not changed).
Exactly this is done in ScriptPaths property.
ps. sorry for my poor english ;)

Original comment by jac....@gmail.com on 10 May 2013 at 6:50

[GoogleCodeExporter]

The internal implementation doesn't rely on Sorted/Duplicate, it's external 
code that can have a use for these, and the compiler actually replicates the 
content in another structure, and doesn't use the one exposed in configuration 
class beyond that replication.

So the list is used there as a utility container, so you don't have to maintain 
another one, rather than an interface that abstracts an internal structure, ie. 
it's unlike TMemo, TListBox, etc. so I'm considering making ScriptPath a 
TStringList as well.

Original comment by zar...@gmail.com on 10 May 2013 at 7:21

[GoogleCodeExporter]

Hmm, I think that we misunderstand together. I expect that Conditionals will be 
TStrings too, and I ask WHY Conditionals is a TStringList? It is a special 
reason?

Original comment by jac....@gmail.com on 10 May 2013 at 9:32

[GoogleCodeExporter]

To be able to perform Sort or apply Duplicates settings on it.

This is not a property that exposes an internal compiler interface, this is a 
storage container, so the idea was that you wouldn't have to maintain a 
separate external structure for conditionals in simple cases.

Is there anything lost by not having a TStrings? AFAICT the only limitation is 
that you can't use ":=" when assigning from a TListBox/TMemo, but have to use 
.Assign()

Original comment by zar...@gmail.com on 10 May 2013 at 11:29

[GoogleCodeExporter]

Ok, now I understand. 
But I was not convinced. I prefer to manage the "Conditionals" outside DWS ;-)

Original comment by jac....@gmail.com on 10 May 2013 at 5:15

[GoogleCodeExporter]

When you use TdwsConfiguration you can use Delphi streaming (or other 
RTTI-based streaming), and it'll support every future option as well (mostly 
useful to allow manual tweaks in a config file without having to expose 
everything in a UI).

Original comment by zar...@gmail.com on 14 May 2013 at 6:58

• Changed state: Done