[#1651] A min/max bug? — "Christoph" <chr_news@...>
Hi,
[#1690] Re: open-uri patch, added progress_proc hook — Elliott Hughes <ehughes@...>
In effect. I mean that if a method's interface is getting too complicated,
In article <AD4480A509455343AEFACCC231BA850F17C358@ukexchange>,
On Sun, Nov 16, 2003 at 07:51:42PM +0900, Tanaka Akira wrote:
[#1699] FileUtils bug and fix — Chad Fowler <chad@...>
As posted in ruby-talk:85349, I believe there is a bug in FileUtils.cp's
[#1706] gc_sweep in Ruby 1.8 — Richard Kilmer <rich@...>
I posted about this before but Matz wanted me to post more detail.
>>>>> "R" == Richard Kilmer <rich@infoether.com> writes:
[#1711] Re: open-uri patch, added progress_proc hook — "T. Onoma" <transami@...>
Tanaka Akira:
On Sunday 23 November 2003 07:12 pm, Mathieu Bouchard wrote:
On Sunday 23 November 2003 08:26 pm, Mathieu Bouchard wrote:
On Sunday 23 November 2003 09:32 pm, Mathieu Bouchard wrote:
On Sunday 23 November 2003 11:13 pm, Mathieu Bouchard wrote:
On Mon, Nov 24, 2003 at 05:32:09AM +0900, Mathieu Bouchard wrote:
[#1716] Re: open-uri patch, added progress_proc hook — "T. Onoma" <transami@...>
Tanaka Akira:
[#1718] Re: open-uri patch, added progress_proc hook — Elliott Hughes <ehughes@...>
In article <AD4480A509455343AEFACCC231BA850F17C434@ukexchange>,
On Saturday 22 November 2003 04:34 pm, Tanaka Akira wrote:
In article <200311221024.05642.transami@runbox.com>,
On Sunday 23 November 2003 02:24 am, Tanaka Akira wrote:
In article <200311230325.21687.transami@runbox.com>,
On Sunday 23 November 2003 03:10 pm, Tanaka Akira wrote:
In article <200311230648.41003.transami@runbox.com>,
On Monday 24 November 2003 03:19, Tanaka Akira wrote:
Sean E Russell [mailto:ser@germane-software.com] wrote:
[#1753] gc_sweep under 1.8 ... not syck.so — Richard Kilmer <rich@...>
We still encountered a gc_sweep in our use of Ruby 1.8 on Linux (v8).
>>>>> "R" == Richard Kilmer <rich@infoether.com> writes:
Yes, there are several (Ruby) threads working during this gc_sweep.
>>>>> "R" == Richard Kilmer <rich@infoether.com> writes:
of course this effects 300 machines ;-)
>>>>> "R" == Richard Kilmer <rich@infoether.com> writes:
The saga continues:
>>>>> "R" == Richard Kilmer <rich@infoether.com> writes:
There is a discussion (found by chad fowler) on ruby-dev (22000)
[#1755] Re: Controlled block variables — Jamis Buck <jgb3@...>
On Mon, 2003-11-24 at 02:04, T. Onoma wrote:
On Monday 24 November 2003 05:22 pm, Jamis Buck wrote:
On Monday 24 November 2003 11:51, T. Onoma wrote:
On Monday 24 November 2003 06:40 pm, Sean E Russell wrote:
On Tue, 25 Nov 2003, T. Onoma wrote:
On Monday 24 November 2003 14:02, T. Onoma wrote:
On Monday 24 November 2003 09:15 pm, Sean E Russell wrote:
[#1799] Syck install on Debian Standard (Ruby 1.6.7) — "T. Onoma" <transami@...>
Hi, I'm having some trouble installing Syck on Debain (woody). I'm not
On Friday 28 November 2003 09:17 am, T. Onoma wrote:
On Fri, Nov 28, 2003 at 05:22:48PM +0900, T. Onoma wrote:
[#1819] Re: configure.in: do not override CCDLDFLAGS, LDFLAGS, XLDFLAGS — Eric Sunshine <sunshine@...>
Hello,
Re: open-uri patch, added progress_proc hook
On Sunday 23 November 2003 02:24 am, Tanaka Akira wrote:
> In article <200311221024.05642.transami@runbox.com>,
>
> "T. Onoma" <transami@runbox.com> writes:
> > opts = OpenUriOptions.new
> > def opts.progress_bar( percent_done )
> > puts "Yeah, we're at " + percent_done + "% now!"
> > end
> > open( "http://whytheluckystiff.net/why.yml", opts )
>
> I can't see any benefits over non-singleton method version:
It's actually kind of mind boggling just how nearly identical these two code
snippets are.
opts = OpenUriOptions.new
opts.progress_bar do |percent_done|
puts "Yeah, we're at " + percent_done + "% now!"
end
open( "http://whytheluckystiff.net/why.yml", opts )
opts = OpenUriOptions.new
def opts.progress_bar( percent_done )
puts "Yeah, we're at " + percent_done + "% now!"
end
open( "http://whytheluckystiff.net/why.yml", opts )
If fact the distinction is wholly in the 2nd line where the do moves over to
def and the | | become ( ). That's it!
And of course the end result is exactly the same. So...
> Why singleton?
There's something compelling about them in conjunction with Duck Typing. But
it has less to do with the front-end, as show here, and more to do with with
the implementation code that underlys these two examples. The distinction is
one of specific/active verses general/passive programming.
The first example requires that the implementation be more active and
specific, taking care of all the assignments to the opts with built in
methods.
class OpenUriOptions
attr_reader :progress_block
def progress_bar( &progress_block )
@progress_block = progress_block
end
end
...
def open(name, opts, &block)
...
opts.progress_block.call(t) if opts.progress_block
...
end
The second is passive and general, and needs do nothing special to gain new
functionality except to ask if it has been given it.
class OpenUriOptions
end
...
def open(name, opts, &block)
...
opts.progress_block(t) if opts.respond_to?(:progress_block)
...
end
So the advantage is having less implementation code. In fact you could write a
whole class that had nearly zero assignment code and all respond_to?
activators. (That would be interseting to see actually.) On the downsie it
might have some small performance loss, and, of course, we're simply not used
to the idea.
Perhaps you see it differently, but for me, not only does it seem odd, but it
feels new and exciting at the same time. But hey, I'm a wild and crazy kind
of guy.
-t0