[#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: Controlled block variables
On Tuesday 25 November 2003 05:47 pm, Sean E Russell wrote: > I know what you mean. I tend to want to scope things up when using irb; > that bites me all the time. However, @ resolves ambiguity: > > If we don't have @, then: > > class Foo > a = "blah" > def bar > a = 1 + 1 > end > end > > What would "a" be? In this trivial case, it may not be a problem. But in > a large class, with a lot of methods, the odds of overriding some instance > variable has a great potential to introduce bugs. Honestly, I have always felt funny about @a = a (Get shivers just looking at it.) And I avoid it like the plague for everything execept assignments in def initialize. You are no doubt correct though, name clashing would have to be considered on a larger scale, though we generally already do so, since many instance variables are attr methods. In which case local varaible gets precedence. To avoid? self.a For an instance variable? That would mean a was a method. And I would say, in a way, it is: It is the attribute reader/writer "method" for the instance variable. This would mean you'd no longer need to do attr_accessor, attr_reader, etc. You might think that this means you could no longer define alternate accessor methods OF THE SAME NAME, but with the addition of method wrapping this problem is solved. Plus, you can still use specialized names for such methods. It also means that internal class code accesses instance variables in the same manner as external code. Like defining an accessor and using self.a/self.a= everywhere. In fact there was discussion of this, way back when, over whether internal code should always use accessors. Of course, we must also take into consideration access control. This is easily solved using the same means used for regular methods: public, protected, private. You also get the upside of getting programmers to use slightly longer more descriptive names to avoid the local clash. I use rather long names, myself, for everything except the occasional iterator var. Obviosly the down side is that the @ is no longer there to immediately give away that it is an instance variable rather then a local varible, but we already deal with this in connection wih methods and local vars. Actually one of the neat things this allows, is to treat @ as simple sugar, such that @a is same as self.a. > Also, how would you > declare an instance variable in a method? > > def Foo > def bar > a = "Foo" # I want "a" to be an instance variable > b = "Bar" # I don't want "b" to be an instance variable > end > end Again, self.a = "Foo" BTW: If your interested in wraps, I've work up a detailed RCR candidate at: http://www.rubygarden.org/ruby?AspectOrientedRuby Sure would appreciate it if others took a gander. -t0 P.S. I can see David's stomach turning now. I imagine he feels this dosen't belong here. We'll okay. I certainly don't wish to offend David. But I feel there's somewhat of a disconnect between our mailing lists. This subject matter dosen't seem to fit well anywhere. On the regular list it tends to be ignored, here accused of impertinence, and obviously it does not belong on dev. So perhaps we need another list? ruby-muse? ruby-tech? Either that, or we should allow such disccusions here to compliment the more specific "code works". Thoughts?