I've studiously avoided the term "flyweight objects" as I have only ever seen it here and didn't really understand its meaning. I'll stick to "Inside-out" which only has meaning in perl terms as far as I am aware.

With regard to the example you describe, that may have made some sense in the world of 8-bit chars as you only need a pool of 256 object, but in the world of UCS, it becomes excessive I think.

Actually, I say only 256 objects, but even that doesn't make any sense to me. It might make sense in a pure OO, conceptual sense to have a seperate object for each char, but it my view its a very strange thing to do.

There are to my way of thinking only two things you can do with a char.

• Use it. Ie. give it to some other object as a parameter.

  Eg. somestring.append('A'); or somestring.append( somechar );

• Or ask it for its ordinal value.

  Eg. 'A'.ord(); or somechar.ord();

So even if you want to represent it at the language level as an object, in terms of what the compiler or interpreter would actually manipulate, it's just a number.

Unless I'm missing something, which is quite possible because I often do, the idea that the compiler/interpreter would manipulate a pointer to an object or worse, a handle to an object at the binary level is simple crazy?

Can you see a reason for having an object to represent each char? I mean, if your are going to allow attributes to be applied to individual chars (color, size, whatever), then pooling the objects isn't going to work because I wouldn't be able to have a red 'A' and a green 'A' at the same time.

I can see the need for being able to maintain and manipulate attributes for aggragations of chars. This string is ascii, that sting is EBCDIC, but doing this at the char level does make any sense (to me). If you could do it, then you could create aggregate strings of mixed ascii and EBCDIC and then what happens when you want to compare string 'T{ascii}h{EBCDIC}e{ascii}' with 'T{EBCDIC}h{ascii}e{EBCDIC}'--do they match or not?