On 6/28/06, Izidor Jerebic <ij.rubylist / gmail.com> wrote:
> On 27.6.2006, at 19:19, Austin Ziegler wrote:
> > As I said, most of my opposition is based on
> > (1) stupid statically typed languages and (2) an inability to tell
> > Ruby what type you want back from a method call (this is a good thing,
> > because it in part prevents #1 ;).
> First, "most of my opposition" is not useful in discussion and is a
> straw-man, because we are not counting people here, we try to
> evaluate reasons for and against. One person with good reason should
> overcome 1000 not-so-good posts. This is not about winning the
> argument, it's about having the best solution.

You have misread my English. I am not referring to people who oppose
my position; I am referring to my opposition to a separate ByteArray
class. However, I have yet to see even a mediocre reason for a
separate ByteArray.

> 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. And type hinting for
return types would be as bad as anything else for Ruby. Consider this
copy function:

  def copy_file(inf, outf)
    open(inf, "rb") { |fin|
      File.open(outf, "wb") { |fout|
        fout.write fin.read
      }
    }
  end

Why didn't I use File.open? Because I can now do this:

  require 'open-uri'
  copy_file("http://www.ruby-lang.org/en", "ruby-lang-en.html")

I didn't get a "File" object from Kernel#open; I got (in this case) a Tempfile.

> Since the rules are not fixed yet, nobody can say whether one or the
> other solution is better. But if the API is not very clear or
> requires lots of manual specifying in code, we will be in a mess,
> similar to today.

Quite simply, you're either wrong or you don't understand the
parameters of the problem. I'd rather assume the latter.

However, if you want to ensure a particular class is returned from a
Ruby method, you must have a method which guarantees that it will only
return that class (or nil, perhaps). Therefore, with a separate
ByteArray class, we would *of necessity* see parallel File operations
or a separate IO class hierarchy or (worst of all!) constructors which
tell the File to return String or ByteArray depending on how it was
constructed.

There is *no possible good argument* for separating ByteArray from
String in Ruby. Not with what it would do to the rest of the API, and
I don't think that anyone who wants a ByteArray is thinking beyond
String issues.

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