Forum: Ruby ruby-dev summary 28206-28273

Announcement (2017-05-07): www.ruby-forum.com is now read-only since I unfortunately do not have the time to support and maintain the forum any more. Please see rubyonrails.org/community and ruby-lang.org/en/community for other Rails- und Ruby-related community platforms.
Minero A. (Guest)
on 2006-02-02 11:38
(Received via mailing list)
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 N. 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 T. 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 N. 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 A.
ruby-dev summary index: http://i.loveruby.net/en/ruby-dev-summary.html
Martin DeMello (Guest)
on 2006-02-02 16:45
(Received via mailing list)
Minero A. <removed_email_address@domain.invalid> wrote:
>
>     h["key"].nil? {|h| h.dispatch }
>
>   This issue is still open.

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
Austin Z. (Guest)
on 2006-02-02 17:18
(Received via mailing list)
On 02/02/06, Minero A. <removed_email_address@domain.invalid> wrote:
>     h["key"] and h["key"].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.)

>     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
unknown (Guest)
on 2006-02-02 17:36
(Received via mailing list)
On Thu, 2 Feb 2006, Minero A. wrote:

>    h["key"] and h["key"].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
Luc H. (Guest)
on 2006-02-02 18:22
(Received via mailing list)
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?

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)
unknown (Guest)
on 2006-02-02 19:40
(Received via mailing list)
Quoting Austin Z. <removed_email_address@domain.invalid>:

> 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
unknown (Guest)
on 2006-02-02 20:01
(Received via mailing list)
On Fri, 3 Feb 2006 removed_email_address@domain.invalid wrote:

> Quoting Austin Z. <removed_email_address@domain.invalid>:
>
>> 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?

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

-a
Daniel B. (Guest)
on 2006-02-02 22:18
(Received via mailing list)
removed_email_address@domain.invalid wrote:
>>                ||
>>
>     harp:~ > cat a.rb
>       a = [ 42 ]
>     #
> kind regards.
>
> -a

(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
Daniel B. (Guest)
on 2006-02-02 22:57
(Received via mailing list)
removed_email_address@domain.invalid wrote:

<snip>

>         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
Joel VanderWerf (Guest)
on 2006-02-03 00:24
(Received via mailing list)
Minero A. wrote:
>     h["key"] &? dispatch

What about

       h["key"].?dispatch

It's more visually similar to the ordinary method call

       h["key"].dispatch
angus (Guest)
on 2006-02-04 13:50
(Received via mailing list)
[Joel VanderWerf <removed_email_address@domain.invalid>, 2006-02-02 23.23 CET]
> Minero A. 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
This topic is locked and can not be replied to.