Ruby-dev summary 28206-28273

ruby-talk
1

Hi all,

This is a summary of ruby-dev ML in these days.

[ruby-dev:28211] GC.stress

  TANAKA Akira proposed a new method GC.stress, which dispatches garbage
  collection more eagerly. This method is useful to debug GC related
  problems.

  Matz agreed to him and this patch is committed in 1.9 branch.

[ruby-dev:28217] ANDCALL operator

  Nobuyoshi Nakada suggested a new operator `&?' (this notation is temporary)
  which evaluates left-hand-side expression, and if it is true then call
  right-hand-side method. For example:

    if a[1] and a[1].strip.empty?
                >>
    if a[1] &? strip.empty?

    h["key"] and h["key"].dispatch
                >>
    h["key"] &? dispatch

  The motivation of this operator is to avoid duplication of expression.

  Takaaki Tateishi proposed another idea, Object#nil? with block
  (again, this name is temporary).

    a[1].nil? {|str| str.strip.empty? }
    h["key"].nil? {|h| h.dispatch }

  This issue is still open.

[ruby-dev:28233] 1.8.5 release plan?

  URABE Shyouhei proposed a rough release plan of Ruby 1.8.5,
  assuming the release date is 1st Apr.

    Week 0 (2/4) : Decide a plan.
    Week 1 (2/11): Prohibit any feature changes on 1.8 branch.
    Week 2 (2/18): Fixing bugs on 1.8 branch.
    Week 3 (2/25): Preview 1; Prohibit non-critical bug fixes.
    Week 4 (3/4) : Validate preview 1.
    Week 5 (3/11): Preview 2; Prohibit non-critical bug fixes without release engineer.
    Week 6 (3/18): Validate preview 2.
    Week 7 (3/25): Preview 3; Prohibit any changes without release engineer.
    Week 8 (4/1) : 1.8.5 release

[ruby-dev:28234] coding pragma

  In 1.9 branch, you can use "coding pragma" to tell the ruby interpreter
  the encoding of program file:

    #!/usr/bin/ruby
    # -*- coding: UTF-8 -*-

  KIMURA Koichi asked when this pragma is backported from 1.9 to 1.8.
  Nobuyoshi Nakada said that is difficult because current implementation
  calls ungetc() many times, which is not assured in C standards. Ruby
  1.9 does not depend on stdio, multiple ungetc() call is not a problem.

  For details of coding pragma, see the thread from [ruby-core:04881].

-- Minero Aoki
ruby-dev summary index: http://i.loveruby.net/en/ruby-dev-summary.html

2

Syntactically, a method might look better than an operator:

a[1].if?.strip.empty?
a[1].maybe.strip.empty?
a[1].and.strip.empty?

martin

···

Minero Aoki <aamine@loveruby.net> wrote:

[ruby-dev:28217] ANDCALL operator

  Nobuyoshi Nakada suggested a new operator `&?' (this notation is temporary)
  which evaluates left-hand-side expression, and if it is true then call
  right-hand-side method. For example:

    if a[1] and a[1].strip.empty?
                >>
    if a[1] &? strip.empty?

    h["key"] and h["key"].dispatch
                >>
    h["key"] &? dispatch

  The motivation of this operator is to avoid duplication of expression.

  Takaaki Tateishi proposed another idea, Object#nil? with block
  (again, this name is temporary).

    a[1].nil? {|str| str.strip.empty? }
    h["key"].nil? {|h| h.dispatch }

  This issue is still open.

3

[ruby-dev:28217] ANDCALL operator

  Nobuyoshi Nakada suggested a new operator `&?' (this notation is temporary)
  which evaluates left-hand-side expression, and if it is true then call
  right-hand-side method. For example:

    if a[1] and a[1].strip.empty?
                >>
    if a[1] &? strip.empty?

    h["key"] and h["key"].dispatch
                >>
    h["key"] &? dispatch

  The motivation of this operator is to avoid duplication of expression.

  Takaaki Tateishi proposed another idea, Object#nil? with block
  (again, this name is temporary).

    a[1].nil? {|str| str.strip.empty? }
    h["key"].nil? {|h| h.dispatch }

  This issue is still open.

I would prefer the latter, but it doesn't completely solve the repeated
expression issue. Worse, the use of #nil? would mean that anyone who has
overridden #nil? would have broken behaviour -- and the behaviour is the
inverse of what I'd expect. (That is, I'd expect the block to be called
*if* the item is nil, not if it isn't nil.)

[ruby-dev:28233] 1.8.5 release plan?
  URABE Shyouhei proposed a rough release plan of Ruby 1.8.5,
  assuming the release date is 1st Apr.

    Week 0 (2/4) : Decide a plan.
    Week 1 (2/11): Prohibit any feature changes on 1.8 branch.
    Week 2 (2/18): Fixing bugs on 1.8 branch.
    Week 3 (2/25): Preview 1; Prohibit non-critical bug fixes.
    Week 4 (3/4) : Validate preview 1.
    Week 5 (3/11): Preview 2; Prohibit non-critical bug fixes without release engineer.
    Week 6 (3/18): Validate preview 2.
    Week 7 (3/25): Preview 3; Prohibit any changes without release engineer.
    Week 8 (4/1) : 1.8.5 release

Might I suggest not having a 4/1 release because of Poisson d'Avril?

-austin

···

On 02/02/06, Minero Aoki <aamine@loveruby.net> wrote:
--
Austin Ziegler * halostatue@gmail.com
               * Alternate: austin@halostatue.ca

4

suggestion:

 harp:~ > cat a.rb
···

On Thu, 2 Feb 2006, Minero Aoki wrote:

[ruby-dev:28217] ANDCALL operator

Nobuyoshi Nakada suggested a new operator `&?’ (this notation is temporary)
which evaluates left-hand-side expression, and if it is true then call
right-hand-side method. For example:

if a[1] and a[1].strip.empty?
>>
if a[1] &? strip.empty?

h[“key”] and h[“key”].dispatch
>>
h[“key”] &? dispatch

The motivation of this operator is to avoid duplication of expression.

Takaaki Tateishi proposed another idea, Object#nil? with block
(again, this name is temporary).

a[1].nil? {|str| str.strip.empty? }
h[“key”].nil? {|h| h.dispatch }

This issue is still open.

 #
 # predicate methods to avoid double evaluation of expr
 #
   module Kernel
     def iff?(a, &b) a.instance_eval &b if a end
     alias_method "if?", "iff?"
     def iff!(a, &b) a.instance_eval &b unless a end
     alias_method "if!", "iff!"
   end

   a = [ 42 ]
   b = [ false ]

 #
 # if, and only if
 #

   iff?(a.first){ p self }

 #
 # if, and only if not
 #

   iff!(b.first){ p self }



 harp:~ > ruby a.rb
 42
 false

kind regards.

-a

–
happiness is not something ready-made. it comes from your own actions.

  • h.h. the 14th dali lama
5

Minero Aoki wrote:

    h["key"] &? dispatch

What about

       h["key"].?dispatch

It's more visually similar to the ordinary method call

       h["key"].dispatch

···

--
        vjoel : Joel VanderWerf : path berkeley edu : 510 665 3407

6

How about replacing '.' by something else in those cases ? Something with a slightly different semantic, like "send message only if the receiver is not nil".

For example, using ':'

if a[1] and a[1].strip.empty? ==> if a[1]:strip.empty?
h["key"] and h["key"].dispatch ==> h['key']:dispatch

(I've tried with various other characters, ':' is the one which looks the best imho)

···

On 2 févr. 06, at 15:43, Martin DeMello wrote:

a[1].if?.strip.empty?
a[1].maybe.strip.empty?
a[1].and.strip.empty?

--
Luc Heinrich - luc@honk-honk.com - http://www.honk-honk.com

7

Quoting Austin Ziegler <halostatue@gmail.com>:

Worse, the use of #nil? would mean that anyone
who has overridden #nil? would have broken behaviour

Out of curiousity, has anyone on this list ever overriden #nil? ?
If so, why?

-mental

8

(Reposted to ruby-talk)

Nice. If only "if" were a Kernel method that we could tie it to back to "if/else" constructs somehow:

iff a.first
    ...
else
    ...
end

Cue the Smalltalk weenies...

Regards,

Dan

···

ara.t.howard@noaa.gov wrote:

On Thu, 2 Feb 2006, Minero Aoki wrote:

[ruby-dev:28217] ANDCALL operator

Nobuyoshi Nakada suggested a new operator `&?' (this notation is temporary)
which evaluates left-hand-side expression, and if it is true then call
right-hand-side method. For example:

   if a[1] and a[1].strip.empty?
               >>
   if a[1] &? strip.empty?

   h["key"] and h["key"].dispatch
               >>
   h["key"] &? dispatch

The motivation of this operator is to avoid duplication of expression.

Takaaki Tateishi proposed another idea, Object#nil? with block
(again, this name is temporary).

   a[1].nil? {|str| str.strip.empty? }
   h["key"].nil? {|h| h.dispatch }

This issue is still open.

suggestion:

    harp:~ > cat a.rb
    #
    # predicate methods to avoid double evaluation of expr
    #
      module Kernel
        def iff?(a, &b) a.instance_eval &b if a end
        alias_method "if?", "iff?"
        def iff!(a, &b) a.instance_eval &b unless a end
        alias_method "if!", "iff!"
      end

      a = [ 42 ]
      b = [ false ]

    #
    # if, and only if
    #

      iff?(a.first){ p self }

    #
    # if, and only if not
    #

      iff!(b.first){ p self }

    harp:~ > ruby a.rb
    42
    false

kind regards.

-a

9

<snip>

suggestion:

    harp:~ > cat a.rb
    #
    # predicate methods to avoid double evaluation of expr
    #
      module Kernel
        def iff?(a, &b) a.instance_eval &b if a end
        alias_method "if?", "iff?"
        def iff!(a, &b) a.instance_eval &b unless a end
        alias_method "if!", "iff!"
      end

<snip>

a = nil

iff?(a.length > 2){ puts "yep" }

undefined method `length' for nil:NilClass (NoMethodError)

I guess we need delayed evaluation. Would Nobu's UDelegator help here?

http://tinyurl.com/7zhzb

Regards,

Dan

···

ara.t.howard@noaa.gov wrote:

10

[ruby-dev:28217] ANDCALL operator

Nobuyoshi Nakada suggested a new operator `&?' (this notation is temporary)
which evaluates left-hand-side expression, and if it is true then call
right-hand-side method. For example:

   if a[1] and a[1].strip.empty?
               >>
   if a[1] &? strip.empty?

   h["key"] and h["key"].dispatch
               >>
   h["key"] &? dispatch

The motivation of this operator is to avoid duplication of expression.

Takaaki Tateishi proposed another idea, Object#nil? with block
(again, this name is temporary).

   a[1].nil? {|str| str.strip.empty? }
   h["key"].nil? {|h| h.dispatch }

This issue is still open.

I have to say, I don't like any of these. Personally, I write

if a
  a.foo
end

because it's simple for anyone to understand, and easy to refactor when you inevitably decide you need to do something else as well as calling the method. If you find it too painful to type the expression twice, I say get a text editor which has dynamic completion, or use a temporary variable if your expression has side effects.

    #
    # if, and only if
    #

      iff?(a.first){ p self }

I dislike this less, because at least it's not an operator. I switched from Perl to get away from those.

Another option would be to call it 'with', and define that with(nil) doesn't execute the block. Then you could just write

with a[1] strip.empty

or

with a[1]
  strip
  empty
end

which would have the side benefit of allowing you to reduce the length of long lines of chained methods.

mathew
[ OK, I admit it, I got the idea from BASIC. ]

11

[Joel VanderWerf <vjoel@path.berkeley.edu>, 2006-02-02 23.23 CET]

Minero Aoki wrote:
> h["key"] &? dispatch

What about

      h["key"].?dispatch

It's more visually similar to the ordinary method call

      h["key"].dispatch

Or &. ?
  k["key"]&.chomp!&.dispatch

···

--

12

once. for a c-pointer extension i was playing with. never really used it
though.

-a

···

On Fri, 3 Feb 2006 mental@rydia.net wrote:

Quoting Austin Ziegler <halostatue@gmail.com>:

Worse, the use of #nil? would mean that anyone
who has overridden #nil? would have broken behaviour

Out of curiousity, has anyone on this list ever overriden #nil? ?
If so, why?

--
happiness is not something ready-made. it comes from your own actions.
- h.h. the 14th dali lama

13

mathew wrote:

with a[1]
strip
empty
end

Sorry, that should of course have been

with a[1]
  strip!
  empty?
end

or similar. Hopefully you get the basic idea anyway, and someone can refine the semantics if they like it...

mathew