On Fri, Mar 27, 2009 at 10:02, Hans-Peter Diettrich <drdiettri...@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 _______________________________________________ Lazarus mailing list Lazarus@lazarus.freepascal.org http://www.lazarus.freepascal.org/mailman/listinfo/lazarus