[Seaside-dev] codecs overhauled (again)

[Philippe Marschall]

2009/6/7 Julian Fitzell <jfitzell at gmail.com>:
> Agreed. I also would still like this protocol to be expressed in terms
> of both an internal and external encoding pair (which I think (?) we
> managed to agree to in principle at the last sprint).
>
> Maybe we don't want to fully implement functionality that uses that
> right now but it might still be a good idea to lay the groundwork for
> it now.
>
> WACodec external: 'utf-8' internal: 'utf-8'.  "an instance of WANullCodec"
> WACodec external: 'latin-1' internal: 'latin-1'.  "an instance of WANullCodec"
> WACodec external: 'utf-16' internal: 'utf-16'.  "an instance of WANullCodec"
>
> WACodec external: 'utf-8' internal: nil.  "an instance of WAUtf8Codec"
> (maybe there's a better value than nil for "native"? #native?)
> WACodec external: 'utf-8'. "equivalent to above"
>
> WACodec external: 'latin-1'.  "an instance of WAGenericCodec"
>
> WACodec external: 'utf-16' internal: 'utf-8'.  "Error: no codec
> supports that encoding pair"
>
> I know this is my agenda item I keep pushing but I do think it will
> help users understand what input and output they should be expecting.
> I can try to find time to do this if you don't want to but I thought
> I'd bring it up again since you were in there anyway.
>
> Also, on another note, do we not want to keep tests that explicitly
> test WAGenericCodec? I see that it's nice to have generic UTF-8 tests
> that just test that there is *some* codec that will do the conversion
> but doesn't it still make sense in the Squeak tests to make sure that
> the generic codec is functioning properly? Right now the tests all use
> "WACodec forEncoding:" which might not even return a WAGenericCodec.

So? I mean they test that the system is working. Isn't it OO to not
care or know which class and code ends up doing the work?

Cheers
Philippe