[#9854] BUG: ruby-yarv 1.9 undefined method `close' for nil:NilClass in ensure — ville.mattila@...
Hello,
[#9864] String#upto edge case - empty string causes infinite loop — Daniel Berger <Daniel.Berger@...>
Hi,
Hi,
On 1/8/07, Yukihiro Matsumoto <matz@ruby-lang.org> wrote:
> -----Original Message-----
On 1/8/07, Berger, Daniel <Daniel.Berger@qwest.com> wrote:
> -----Original Message-----
On 1/9/07, Berger, Daniel <Daniel.Berger@qwest.com> wrote:
[#9869] a block argument within a block which argument has the same name leaks — <noreply@...>
Bugs item #7680, was opened at 2007-01-08 22:53
Hi,
On Jan 8, 2007, at 2:30 PM, Yukihiro Matsumoto wrote:
Hi,
Hi --
Hi,
Hi --
Hi,
Hi,
Evan Phoenix wrote:
Hi,
Yukihiro Matsumoto wrote:
Hi,
On Jan 10, 2007, at 8:43 AM, Yukihiro Matsumoto wrote:
Hi,
Hi,
Hi,
[#9897] Time Zone printing differently for 1.8.4 and 1.8.5. — "Jim Freeze" <jim@...>
> ruby -rparsedate -ve 'puts Time.mktime(* ParseDate.parsedate("Thu Nov 02
[#9908] rdoc for 1.8.5 not creating Module docs? — James Britt <james.britt@...>
When running rdoc over the current 1.8.5 source, the resulting HTML file
[#9926] Fix for File and File::Stat to deal with bogus stat.st_size member — <noreply@...>
Patches item #7760, was opened at 2007-01-11 14:26
On Fri, 12 Jan 2007, noreply@rubyforge.org wrote:
> -----Original Message-----
On Sat, 13 Jan 2007, Berger, Daniel wrote:
[#9949] sandbox 0.4 (r115) with a new patch — _why <why@...>
Okay, here's the latest release of the freaky freaky sandbox.
[#9959] anonymous classes share single alloc function — <noreply@...>
Bugs item #7974, was opened at 2007-01-18 13:28
[#9960] Scoping and locating definitions — Jos Backus <jos@...>
Consider the following:
Jos Backus schrieb:
On Fri, Jan 19, 2007 at 06:40:03PM +0900, Pit Capitain wrote:
On Sat, Jan 20, 2007 at 02:18:19AM +0900, Jos Backus wrote:
On 1/20/07, Jos Backus <jos@catnook.com> wrote:
Jos Backus schrieb:
On Sun, Jan 21, 2007 at 04:39:52AM +0900, Pit Capitain wrote:
Jos Backus schrieb:
[#9969] Allowing Unicode in the grammar? — "Berger, Daniel" <Daniel.Berger@...>
Hi Matz,
[#9996] new method dispatch rule (matz' proposal) — SASADA Koichi <ko1@...>
Hi,
Hi,
It's late for me here, so I have just brief comments below...
Hi,
SASADA Koichi wrote:
Hi,
On Jan 23, 2007, at 7:41 AM, Yukihiro Matsumoto wrote:
On Tue, 23 Jan 2007, James Edward Gray II wrote:
Hi,
Yukihiro Matsumoto wrote:
Hi,
Yukihiro Matsumoto wrote:
Hi,
The more this discussion goes on, the more I worry that Joe Q Public
Hi,
[#10019] stable branch policy & schedule for 1.8.6 — "Akinori MUSHA" <knu@...>
Core developers,
Akinori MUSHA wrote:
Charles Oliver Nutter wrote:
On Jan 23, 2007, at 22:13, Joel VanderWerf wrote:
At Wed, 24 Jan 2007 15:13:52 +0900,
Hello,
Hi,
[#10066] class variables and inheritance — <noreply@...>
Bugs item #8156, was opened at 2007-01-25 15:05
[#10068] Re: Method Dispatch (was Adding methods to String, but only in my own Module?) — gwtmp01@...
[#10085] Collaborative Ruby Language Specification — "John Lam (CLR)" <jflam@...>
Hi Everyone,
On 1/28/07, John Lam (CLR) <jflam@microsoft.com> wrote:
Hi --
>> I'm not sure what there is to be non-neutral about :-)
Hi --
On Mon, 29 Jan 2007, dblack@wobblini.net wrote:
John Lam (CLR) wrote:
> I hope such a spec would be developed "in the open" from the beginning,
M. Edward (Ed) Borasky wrote:
-----BEGIN PGP SIGNED MESSAGE-----
On 1/30/07, Eustaquio Rangel de Oliveira Jr. <eustaquiorangel@yahoo.com> wrote:
On 1/30/07, Nikolai Weibull <now@bitwi.se> wrote:
> > I was checking some CLR opinions and - correct me please if I'm wrong - seems
[#10114] add usage of uri.userinfo to open-uri.rb — <noreply@...>
Patches item #8309, was opened at 2007-01-30 15:25
On 2007/01/31, at 06:07, Yukihiro Matsumoto wrote:
Hi,
On Thu, Feb 01, 2007 at 01:19:34AM +0900, Yukihiro Matsumoto wrote:
Hi,
Hi matz,
Hi,
On Feb 2, 2007, at 7:40 PM, Yukihiro Matsumoto wrote:
[#10135] Another .document patch. — Hugh Sasse <hgs@...>
I have been looking at the tips for irb at:
Re: new method dispatch rule (matz' proposal)
The more this discussion goes on, the more I worry that Joe Q Public programmer isn't going to be able to properly grasp these new rules. Everyone here is pretty much the creme de la creme of ruby core developers and we're all still having troubles get our minds around it (or at least I am). Let me propose a change to the rules that might help clean them up. Change rules 3 and 4 to be one rule that reads: "If functional style calling is used, say foo(1), foo is looked up first in the method table of the defining class as a private method. If it is not found, normal dispatch occurs." This change means that no extended lookup is performed to find private methods, only the module that defined the current method is looked for the new method. This means that no subclasses can call superclass private methods, but really thats ok. A subclass probably shouldn't be digging in and calling the private methods of it's superclass anyway, the method isn't very private then. This simplifies the implementation picture as well. Thoughts? - Evan On Jan 23, 2007, at 6:37 PM, Yukihiro Matsumoto wrote: > Hi, > > In message "Re: new method dispatch rule (matz' proposal)" > on Wed, 24 Jan 2007 11:19:37 +0900, Daniel DeLorme <dan- > ml@dan42.com> writes: > > |So private and public methods *do* have different namespaces, in > |a certain way. While you can't have 2 methods with the same name > |in a given class, the private "chain" is pretty much independant > |from the public chain. > > Yes. > > |But the public chain is very much dependant > |on the private chain: > | > | class A > | private > | def bar; "A"; end > | end > | class B < A > | def bar; super+"B"; end > | end > | class C < B > | def bar; super+"C"; end > | end > | C.new.bar #=> "AC" > | > |Am I correct in guessing that the super in C#bar would first look > |in the private method space and find A#bar, skipping B#bar? Or > |would 'super' have a different mechanism, bypassing private/public > |visibility? > > When the method is public, super looks for its public super. That is, > super in C#bar calls B#bar which is public, then super in B#bar tries > to find a public #bar in B's superclass. But A#bar is private (and I > assume there's no public #bar defined in Object either), thus B#bar > raises NoMethodError. > > |Sorry about all the questions. I'll admit that this mixing of > |private and public methods is unlikely to happen in the real world, > |but I'm trying to wrap my mind around all the implications of this > |dispatch model and it's not easy. > > You don't have to be feel sorry. It is a great chance to find a hole > (or holes) in my idea. > > matz. >