[Lazarus] Easiest way to "case" strings

[Alexander Klenin]

On Fri, Mar 27, 2009 at 10:02, Hans-Peter Diettrich
<DrDiettrich1 at aol.com> wrote:

>> Note that I said "with defined equality". The reason 'case' should not include
>> floating point numbers is that equality if not usefully defined for them.
>
> The same for strings, where mere binary (case sensitive) equality often
> is useless.
Well, we should get rid of 'operator = (String, String)' then ;-)
Seriously, I think you are exaggerating here.

> Furthermore Pascal 'case' supports ranges, which deserve a stricter
> order than only equality. Then the sort order of strings also depends on
> the encoding (codepage, MBCS, UTF...).

Heh, I indeed forgot about ranges. Their existence actually allows to implement
a useful 'case' for floating point types, so I now support a 'case of
real' also.
As for sorting order -- just do what built-in inequality does, there
is no reason
to deviate.

> And last not least strings IMO are complex types (array of char), as
> they have been in Wirth Pascal.
Yes, but Object Pascal choose to _not_ follow
Wirth's design here, so in Object Pascal strings are not 'array of char'.

> The order of a comparison of ordinals is
> O(1), whereas string comparison is O(n).
Still, to compare given string with length n with m constant strings,
O(n + m) time is sufficient, which, as I already stated, is another reason
to implement string 'case' ;-)

>> [regarding 'case of string']
>>> Yes. But since this is not a simple type, but a complex type, it goes to a
>>> different class. If that is your argument, make sure it works for arrays, records,
>>> classes, interfaces and the other complex types too.
>> I definitely agree that 'case' should work for classes --
>> perhaps even more important than for strings. For records and static arrays
>> it could be implemented, but the value of such feature would be truly marginal.

There is indeed a problem with ranges of classes.
Maybe interpret them using inheritance as a partial ordering?
E.g. TPersistent..TComponent is ok, but TButton..TDataset is error?

> I.e. what's the literal value and representation of the case label for an record?
Record constant of course.

> What for 'RecA..RecX:'?
I'd say it is RecA.F .. RecX.F for each record field, field recursively.

As I already said, I am not really in favor of 'case of record',
although you have already
convinced me to support the 'case of real'. Still, here is a possible
usage sample for the former:

case MyPoint of
(x:-1, y:-1): ProcessEmptyPoint;
(x:0, y:0)..(x:100, y:100): ProcessPoint;
else InvalidPoint;
end.

-- 
Alexander S. Klenin