[fpc-devel] Re: enumerators

[Marco van de Voort]

In our previous episode, Hans-Peter Diettrich said:
> > 
> > I don't consider it an extreme, on the contrary. Trying to fix this is
> > extreme IMHO.
> 
> Sorry, I understood that you want to replace all for loops by iterated 
> loops.

Only the ones where surrogates really matter. 
 
> >>> And in memory.
> >> That's the design flaw, IMO. When UTF-8 strings are re-encoded before 
> >> processing,
> > 
> > How, when? How do you avoid repeated encoding/decoding/encoding cycles?
> 
> The encoding is only changed on demand. 

> Once converted into a computational format (e.g.  UCS2), the internal
> representation deserves no more changes.  Another conversion may occur
> when a copy in a different encoding is requested; since a copy operation
> already is O(n), a conversion will not increase that order.

This sounds awfully like the argument long ago that ansistrings wouldn't
eventually be slower than strings, since the optimizer would optimize nested
inc/decref calls away, so that there would be no more than
one call per string per procedure.  Afaik, I'm still waiting (and realize
now that it is a lot harder since the refcount has to match pretty closely
due to e.g. the possibility of exceptions)

Yes, you can throw it all on future optimization, but I more a one bird in
the hand kind of guy.

> The result were a general Unicode string class, not bound to a specific 
> encoding, similar to the Delphi Unicode string representation.

I see no implementation details here at all that supports such statement. I
see a wish, not a plan. The devil is always in the details.

> > I don't see why a string should be a class. In FPC it is already a first
> > class type.
> 
> Name it as you like, but a first class string type is only a container, 

... of chars.

> that can contain data of any kind - every data type or structure can be 
> seen as a collection of bytes or chars.

I don't see the any kind stuff. Yes, every type that has a variable memory
footprint can store everything in theory, but that is as far as it goes.

> Take Unicode, zip or graphics encodings as examples for data types, that 
> can be stored in such a container, and you'll see that every different 
> encoding deserves different support functions - the data type becomes 
> polymorphic.

1. I don't see zip or graphics encodings
2. Since there are some variable requirements on the type, I don't see a
good reason to scale that up to "all"


> Having reached that point I see a need for a base class, that reflects the
> *nature* of the information, from which classes for specific encodings can
> be derived.  A user will be happy with the abstract type (see TStrings),
> and must not bother with specific encodings, that can result in bad
> behaviour when not choosen properly.

You totally lost me here.