[#407] New feature for Ruby? — Clemens.Hintze@...

Hi all,

27 messages 1999/07/01
[#413] Re: New feature for Ruby? — matz@... (Yukihiro Matsumoto) 1999/07/01

Hi Clemens,

[#416] Re: New feature for Ruby? — Clemens Hintze <c.hintze@...> 1999/07/01

On Thu, 01 Jul 1999, Yukihiro Matsumoto wrote:

[#418] Re: New feature for Ruby? — gotoken@... (GOTO Kentaro) 1999/07/01

Hi

[#426] Re: New feature for Ruby? — gotoken@... (GOTO Kentaro) 1999/07/02

Hi,

[#440] Now another totally different ;-) — Clemens Hintze <c.hintze@...>

Hi,

21 messages 1999/07/09
[#441] Re: Now another totally different ;-) — matz@... (Yukihiro Matsumoto) 1999/07/09

Hi,

[#442] Re: Now another totally different ;-) — Clemens Hintze <c.hintze@...> 1999/07/09

On Fri, 09 Jul 1999, you wrote:

[#443] — Michael Hohn <hohn@...>

Hello,

26 messages 1999/07/09
[#444] interactive ruby, debugger — gotoken@... (GOTO Kentaro) 1999/07/09

Hi Michael,

[ruby-talk:00427] Re: New feature for Ruby?

From: Clemens Hintze <c.hintze@...>
Date: 1999-07-02 22:44:20 UTC
List: ruby-talk #427
On Fri, 02 Jul 1999, you wrote:
>Hi, 
>
>In message "[ruby-talk:00423] Re: New feature for Ruby?"
>    on 99/07/02, Clemens Hintze <c.hintze@gmx.net> writes:
>
[...]

>I hope so. Though, I believe that the appearence of newsgroup is a
>result of pupularization rather than a method to spread.  To difuuse
>Ruby into the world, we may need another strategic publication.

You're right! I try to mention Ruby among my fellows, whenever I have
an opportunity. But it is not enough, I feel. I have thought about
writing some articles in our computer magazins, but I don't know,
whether my abilities are enough to write an magazin article.

>
>>>Some elements have no natural predecessor; What is `"a".pred'?  
>>>And I think such iteration is too complex to generalize by Range. 

I have defined, that `"a".pred' results in "". String increment and
decrement are magical. We can define, what it means! Okay... whether
it makes sense or not, is another issue. So we are discussing here :-)

[...]

>I see. But as you point out, I have a different image of Interval
>rather than Cle or Matz.  `Interval' reminds me a class managing
>membership, because the most familiar interval for me is `an interval
>on real number' wheare as you guys supporse to use Interval to
>itarations. I'm interested in an native speaker's sense of words.
>Julian? or Bryce?

I have used it in terms of Smalltalk. In Smalltalk I can use

   (1 to: 10) do: [:i| ...]

In Smalltalk, the method Integer::to: will create an Interval. I
should mention that in Smalltalk

   Interval < FixedSizeCollection < IndexedCollection < Collection

and there exists methods (e.g. Collection#do:) to iterate over
Collections. So in Smalltalk, instances of class Interval are mostly
used for iteration purposes! BTW: an Interval in Smalltalk is defined
as: "... finite arithmetic progression." it "... contains all the
elements within a specified range and with a specified distance
between each of them, ...".

[...]

>>
>>   interval("a", "z").included?("c")
>
>How about `("a".."z") === "c"'?
>But your interval would be devoted to iteration, isn't it?

I have already thought of it! I aggree. I think it really makes no
sense to use an Interval where I can use a Range too!

But as an Interval should be a iteration which also is a
enumeration, (I plan to include Enumeration), the
`Interval#include?' method would automatically creeps in! :-)

>
>By the way, I've felt not good the name of Array#include?.  It should
>be `has?' because `include' reminds mathematicians `subset check',
>i.e., ``["foo", "bar", "baz"].include? ["foo", "baz"] #=> true''

Let me have a check... <klickedi> <klackedi>... okay I understand
now. Array also includes the module Enumeration. So it also haves the
both methods `Enumeration#include?' and `Enumeration#member?'. But it
seems, that the `Array#include?' method overwrites the one of
Enumeration for the sake of speed (matz?)

I think it is an advantage to let all classes which could iterate
over its elements be an Enumeration, and use all the same methods, so
that I have not to look, what name I've to use for the
class-of-the-day! :-)

>
>>>Again, we should mind that negative options are limited. 
>>
>>No! Please not! I think for strings it can make sense to have such
>>magic behavior.
>
>I maybe don't need that. All my anxity is defference between succ and
>pred.  `pred' shall behave as same as succ(-1) then pred may have
>implicit restrictions because, I say again, some objects have no
>suitable predecessor. Furthermore, such restriction is needed for not
>only strings but also for nutural numbers like a Julius date. In such
>sense, the predecessor is a quite different notion than the successor. 
>We should mind it. I don't see whether or not that is serious
>difference. Of course that can be avoided by raising an error:
>"a".pred #! Error

That, I think, is the best way. Every class, which does not implement
`succ' cannot be used for raising intervals; every which lacks a
`pred' method cannot be used for falling intervals. That would be
fair, and open a door to generality! What do you think?

If it is only the name Interval, that disturbes you, please offer some
others so that we can discuss them. :-)

You know, the big difference between an Array and an Interval would
be, that all elements of an Interval depends on each other. So it is
not necessary to store them all, but only the start, the stop and the
increment. All other positions would be calculated. That can save
much memory!

>
>-- gotoken

\cle

In This Thread