From: matz@... (Yukihiro Matsumoto)
Date: 2000-03-06T15:26:18+09:00
Subject: [ruby-talk:01749] Re: ruby <=> python


In message "[ruby-talk:01723] Re: ruby <=> python"
    on 00/03/04, Quinn Dunkan <quinn@envy.ugcs.caltech.edu> writes:

|> Strings are used to represent character strings, and sometimes packed
|> structure using pack().  Have you ever used Perl's pack()?
|
|They are in most other languages too, it's just a question of what comes out
|when you throw a [] method at them (most other languages give you a byte, but
|ruby doesn't).

I think a byte is a integer in range between 0 and 255, Ruby does give
you a integer from 0 to 255 by [], although it does not provide the
special type for the range.  Do you mean there's need for a integer
type to represent a byte only?

If so, what characteristics a byte type should have?  What is the
difference between signed int and byte.

|> Because I felt using `::' to access class method was a good idea,
|> e.g. foo = SomeClass::new().  It denotes something (`new' in this
|> case) belongs to the class.
|
|But it doesn't, it works for instance methods too.  And `.' works for `class
|methods' like new.  I know I'm not going to get far arguing with the creator
|of the language :), but what's the rationale for `::' being a good idea?  I'm
|not even sure about the Constant part: the user already knows he's accessing a
|constant because of capitalization, right?  Now he has to remember to use a
|different operator as well.  And if `::' can be used in all situations where
|`.' would be, it doesn't help much from a `make different kinds of access
|visually different' point of view.

I'm not sure I understand your point, mostly because my English skill.
`::' is needed for nested constant access.  Its syntax is

  A::F

There are other combinations like:

  A::F()
  A::f
  A::f()

I made these method invocation to allow programmer to add optional
information to show the receiver is a class.  This is not enforced by
the language, just as a optional variation.

|> `false' is a boolean value, `nil' is a out-of-range value.  You know I mean?
|> I'm considering make 0 false, but not positively.
|
|Uh oh, does that mean only -0 is false?  My head hurts.

NO.  I mean I had considered to make 0 falise; I haven't refused it
yet, but not eager to adpot.  `positively' did not mean number
positiveness.

|> Pros:
|> 
|>   * easier to adopted by C programmers
|>   * easier to adopted by C libraries (e.g. by SWIG)
|
|I don't consider these pros: ruby is already different enough from C that
|similarities might just confuse them more.  And don't forget not everyone's a
|C programmer (but then many other languages say 0 == false, but anyone who
|knows more than a few will know to not take this for granted).

Yes, they are not very strong pros, even though making SWIG easier
may help extension writers.

|> Cons:
|...
|>   * both nil and 0 serve as out-of-range mark, confusing
|
|Does it have to?  Pardon me if I misunderstand, but everything that returns
|nil now can still return nil in the future, ne?  I think it would be more
|confusing (in a certain way) because then there would be 3 false values
|instead of just 2, and it would give the impression that 0.0, '', [], etc.
|ought to also be false.  And then you'd have to supply a false? method like
|python's __nonzero__ :)

No, that's why this is under cons.

|> There's no such idiom yet.  Although I've never met that situation,
|> but I'd do pop (or unshift) from each arrays.
|
|Err, but that modifies the arrays.  I almost never want to modify things, and
|even if it doesn't matter it makes me very nervous.  Maybe just my functional
|background..

You can solve this by defining external iterator.
 
  class ArrayIterator
    def initialize(ary)
      @ary = ary
      @index = 0
    end
    def next
      if @index >= @ary.size
        raise IndexError, "index out of range"
      end
      value = @ary[@index]
      @index += 1
      value
    end
  end

  def zip(*args)
    r = []
    iter = args.collect{|i|ArrayIterator::new(i)}
    begin
      loop do
	r.push iter.collect{|i|i.next}
      end
    rescue IndexError
    end
    r
  end