Alexander Klenin schrieb: > 2) Iterating over characters in string -- at first, it seems no > different from any other array, > but consider UTF-8 strings. Using s[i] notation in a loop will lead to > O(n^2) time, > while 'for ... in' can generate linear-time code.
Please note that for an iteration over UTF-8 strings the data type 'string' is required, to hold the equivalent of a multi-byte UTF "character". Unless there exist data types for both UTF8String and UTF8Char, or MBCSString and MBCSChar etc., a 'for ... in' construct is rather useless. > 3) Iterating over hash, tree, dataset, or really anything more complex > than an array -- > there is currently no language support for that, which leads to many > awkward, buggy and incompatible implementations. IMO the same as for strings. As is, the compiler can only handle basic types, where e.g. a string is an array of fixed size elements (Char, WideChar), with consequently a fixed length. Everything else can be supported only by according class methods or user-supplied operators, which again open the chance for different operators in different units, projects, libraries... > [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. How would you define the equality and ranges of such types? I.e. what's the literal value and representation of the case label for an record? What for 'RecA..RecX:'? DoDi _______________________________________________ Lazarus mailing list [email protected] http://www.lazarus.freepascal.org/mailman/listinfo/lazarus
