ruby-dev summary 28206-28273
Minero Aoki
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
Martin DeMello
>
> [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.
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
ara.t....@noaa.gov
> [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
--
happiness is not something ready-made. it comes from your own actions.
- h.h. the 14th dali lama
Berger, Daniel
> From: Martin DeMello [mailto:martin...@yahoo.com]
> Sent: Thursday, February 02, 2006 7:43 AM
> To: ruby-talk ML
> Subject: Re: ruby-dev summary 28206-28273
>
>
> Minero Aoki <aam...@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.
Yuck. Looks like a hack from Perl6. Not Ruby-ish.
> 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
Looks better syntactically, but still has problems as Austin pointed
out.
I'd sooner accept "iff" (if and only if):
iff h["key"].dispatch -> same as: h["key"].dispatch if h["key"]
But, the idea of adding new keywords doesn't thrill me and I worry that
it's too terse.
Regards,
Dan
Luc Heinrich
> 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)
--
Luc Heinrich - l...@honk-honk.com - http://www.honk-honk.com
men...@rydia.net
> 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
ara.t....@noaa.gov
once. for a c-pointer extension i was playing with. never really used it
though.
Martin DeMello
> > a[1].if?.strip.empty?
> > a[1].maybe.strip.empty?
> > a[1].and.strip.empty?
> >
> > martin
>
> Looks better syntactically, but still has problems as Austin pointed
> out.
Didn't see that post :( Hopefully it'll show up on the ng side sometime
soon. The only problem I can see with it is that you get the method call
overhead even if it does nothing.
> I'd sooner accept "iff" (if and only if):
>
> iff h["key"].dispatch -> same as: h["key"].dispatch if h["key"]
>
> But, the idea of adding new keywords doesn't thrill me and I worry that
> it's too terse.
My strong objection to this is that it breaks the ". binds more tightly
than anything else" rule.
martin
Daniel Berger
(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 Berger
<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?
Regards,
Dan
Eric Hodel
>> Minero Aoki <aam...@loveruby.net> wrote:
>>>
>>> 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.
>
> Yuck. Looks like a hack from Perl6. Not Ruby-ish.
Looks more like Smalltalk, but should be not_nil?.
--
Eric Hodel - drb...@segment7.net - http://segment7.net
This implementation is HODEL-HASH-9600 compliant
Joel VanderWerf
> 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
angus
> 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
--