On 6/28/06, Izidor Jerebic <ij.rubylist / gmail.com> wrote:
> On 28.6.2006, at 18:48, Austin Ziegler wrote:
>>> About (2), inability to tell in advance in your program whether you
>>> get bytes or characters from a method in core (or any other) API is
>>> NOT a good thing. This causes innumerable problems and unexpected
>>> behaviour if programmer expects one and code sometimes gets the
>>> other. The API should prevent such errors, either by very simple and
>>> strict rules that enable easy prediction, or by introducing
>>> ByteArray, which makes prediction trivial. This is not about duck-
>>> typing, it's about randomly having semantically different results.
>> You'll *never* get that without type hinting.
> I think you do not understand what the problem is, because your claim
> is so obviously false.

Oh, bollocks. Go ahead, pull the other one.

> How can I get that with very simple rule: all IO#read (and similar)
> calls always return binary Strings.
>
> No type hinting in sight, but I always know whether my code receives
> Strings or binary Strings. But this simple option is clearly not
> possible, because it complicates the text processing in simple
> scripts. We'll see how complicated the final rules will be.
>
> Alternative (actually equivalent) to the above is: all IO#readbytes
> calls return ByteArray objects, and we need separate call
> IO#readstring which always return Strings with encoding.

Nope. Not nearly equivalent and a lot dumber. I've just spent the last
week explaining in simple terms why it's dumb. You want to *at least*
double the complexity of the IO API because you're either unwilling or
incapable of considering anything but your ByteArray concept.

I, for one, am not willing to consider an extensively more complex API
because your imagination is lacking.

-austin
-- 
Austin Ziegler * halostatue / gmail.com * http://www.halostatue.ca/
               * austin / halostatue.ca * http://www.halostatue.ca/feed/
               * austin / zieglers.ca